[XML-SIG] Python package name
Guido van Rossum
Thu, 21 Sep 2000 10:38:04 -0500
> 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.
We're using lib/python2.0, and we plan not to make major releases with
a 3rd level version number increment! SO I think that's not necessary.
> 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:
> 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... ;-)
You've got it. Please move this to python-dev. It's good PEP
> > > 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.
Overrides of the stdlib are dangerous in general and should not be
> > > 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.
Here's another half-baked idea about versions: perhaps packages could
have a __version__.py file?
--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)