[Python-Dev] Versioning for Python packages

M.-A. Lemburg mal@lemburg.com
Thu, 21 Sep 2000 23:28:47 +0200


[Moved to python-dev from xml-sig]

Guido van Rossum wrote:
> 
> > 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.

Ah, that's good news :-)
 
> > 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... ;-)
> 
> You've got it.  Please move this to python-dev.  It's good PEP
> material!

Done.
 
> > > > 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
> encouraged.
> 
> > > > 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?

Hmm, I usually put a __version__ attribute right into the
__init__.py file of the package -- why another file ?

I think we should come up with a convention on these
meta-attributes. They are useful for normal modules
as well, e.g. __version__, __copyright__, __author__, etc.

Looks like its PEP-time again ;-)

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