[XML-SIG] Python package name

[M.-A. Lemburg]

Guido van Rossum wrote:
> 
> > Wouldn't the whole situation be much easier to handle if
> > lib/python2/site-packages was searched *before* lib/python2 ?
> >
> > That way, newly installed packages could effectively completely
> > override stdlib packages.
> 
> Not necessarily -- 2.1 will install in lib/python2, so an older
> xml package in site-packages would override the newer one from 2.1!
>
> It seems we may have to start thinking about a package versioning
> mechanism!

Perhaps a good start would be using lib/python-2.0.0 as installation
target rather than just lib/python2. I'm sure this was discussed
before, but given the problems we had with this during the 1.5
cycle (with 1.5.2 providing not only patches, but also new
features), I think a more fine-grained approach should be
considered for future versions.

About package versioning: how would the version be specified
in imports ?

from mx.DateTime(1.4.0) import now
from mx(1.0.0).DateTime import now
from mx(1.0.0).DateTime(1.4.0) import now

The directory layout would then look something like this:

mx/
	1.0.0/
		DateTime/
			1.4.0/

Package __path__ hooks could be used to implement the
lookup... or of course some new importer.

But what happens if there is no (old) version mx-1.0.0 installed ?
Should Python then default to mx-1.3.0 which is installed or
raise an ImportError ?

This sounds like trouble... ;-)
		
> > We will have a similar problem with Unicode and the stdlib
> > during the Python 2.0 cycle: people will want to use Unicode
> > together with the stdlib, yet many modules in the stdlib
> > don't support Unicode. To remedy this, users will have to
> > patch the stdlib modules and put them somewhere so that they
> > can override the original 2.0 ones.
> 
> They can use $PYTHONPATH.

True, but why not help them a little by letting site
installations override the stdlib ? After all, distutils
standard target is site-packages.

> > BTW, with distutils coming on strong I don't really see a
> > need for any hacks: instead distutils should be given some
> > smart logic to do the right thing, ie. it should support
> > installing subpackages of a package. If that's not desired,
> > then I'd opt for overriding the whole package (without any
> > hacks to import the overridden one).
> 
> That's another possibility.  But then distutils will have to become
> aware of package versions again.
 
This shouldn't be hard to add to the distutils processing:
before starting an installation of a package, the package
pre-install hook could check which versions are installed
and then decide whether to raise an exception or continue.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/