bytecode non-backcompatibility

Mike Meyer mwm at mired.org
Sat Apr 30 17:40:05 EDT 2005


Maurice LING <mauriceling at acm.org> writes:
> So if C extension API (or whatever that is really called) is stable,
> the system admin can just copy all of /sw/lib/python2.3/site-packages
> into /sw/lib/python2.4/site-packages and it should work. From what
> you've said, it seems that this isn't possible.

Correct. This isn't possible. It's not clear it's *desirable*,
either. For one thing, code can fail to port across versions, so
things will break at random (instead of all at once, I admit). For
another, I dislike the idea of a module sitting unupdate for long
periods of time (decades, say). Updating Python provides a good excuse
to update all the python modules, etc.

Now, it would be nice if Python provided an easy way to do the
update. The FreeBSD packaging system happens to provide a way to
automate this process, but it's still not exactly easy.

> So my alternative
> solution is that PyPI have a mechanism to maintain what had been
> installed in the site-package directory and to download the libraries
> and install into the new site-package directory...

PyPI is the wrong place to maintain a record of installed
software. Distutils is the software that does the installing (ok, on
most modules, anyway), and is the software that should record what
packages are installed.

Neither distutils nor PyPI has a "download" functionality. For that
matter, PyPI doesn't have a hard requirement on listing where a module
comes from. I'd say distutils is the software that should provide it,
so I can say:

   python setup.py install --depends

and get all the dependencies. But that's not at all clear. PyPI will
have to cooperate by providing URLs to packages, instead of to pages.

     <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.



More information about the Python-list mailing list