Any chance of getting one of the proposed solution into Python 2.3 ? http://www.python.org/peps/pep-0297.html -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

MAL, I think an idea like this is good, but I have one concern. Let's say Python 2.3 comes out with email pkg 2.5. Later I find some bugs and release email 2.5.1 and also fix the Python 2.3 maint branch. Now Python 2.3.1 comes out. At best the email package in system-packages should be ignored. At worse, it /has/ to be ignored. E.g. Python 2.3.2 comes out with email 2.5.2. My suggestion is that the Python micro-release number be included in the path to system-packages. IOW, system-packages must exactly match the Python version number, not just the maj.min number. -Barry

...

...

...

...

"GvR" == Guido van Rossum writes:

GvR> Excellent point. GvR> Or a micro-release should clear out the system-packages GvR> directory. The only reason I'd rather not do that is so that if a package still needs an update for the new Python micro release, a sysadmin could at least copy the package over from one version to the next. -Barry

...

GvR> Or a micro-release should clear out the system-packages GvR> directory.

The only reason I'd rather not do that is so that if a package still needs an update for the new Python micro release, a sysadmin could at least copy the package over from one version to the next.

+1

Ok, then, let's call the dir "site-upgrades-<pyversion>" with <pyversion> being major.minor.patchlevel.

+1

It seems that only site.py needs to be changed. Hmm, but what happens if someone invokes Python with -S (don't load site.py) ?

They deserve what they get; they'll have to do their own sys.path manipulation. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:

...

...

GvR> Or a micro-release should clear out the system-packages GvR> directory.

The only reason I'd rather not do that is so that if a package still needs an update for the new Python micro release, a sysadmin could at least copy the package over from one version to the next.

+1

Ok, then, let's call the dir "site-upgrades-<pyversion>" with <pyversion> being major.minor.patchlevel.

+1

...

It seems that only site.py needs to be changed. Hmm, but what happens if someone invokes Python with -S (don't load site.py) ?

They deserve what they get; they'll have to do their own sys.path manipulation.

Ok, I've started looking at adding support for this. Here's a couple of things I found: * getpath.c: Some of the '/' path delimiters are hard coded; shouldn't these be replaced with SEP ? * There's no easy way to find the first item on sys.path which starts the default path added by Python at startup time. It seems that a suffix search for "python23.zip" gives the best hint. The only other possibility I see is writing the support code directly into getpath.c. * site.py contains code which prefixes "site-packages" with both sys.prefix and sys.exec_prefix. Is this really used anywhere ? (distutils and the old Makefile.pre.in both install to sys.prefix per default) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

Guido van Rossum wrote:

...

Ok, I've started looking at adding support for this. Here's a couple of things I found:

* getpath.c: Some of the '/' path delimiters are hard coded; shouldn't these be replaced with SEP ?

All the platforms that I'm awware of that don't use '/' have their own getpath.c copy anyway (the one for Windows is PC/getpathp.c).

But can't hurt to change these in the standard getpath.c, right ? (reduce() is looking for SEP, so on platforms which do use the standard getpath.c but have a different os.sep could be mislead by the hardcoded slash in some constants)

...

* There's no easy way to find the first item on sys.path which starts the default path added by Python at startup time. It seems that a suffix search for "python23.zip" gives the best hint. The only other possibility I see is writing the support code directly into getpath.c.

That's where I'd put it, yes.

You mean "put it into getpath.c" or "put it in front of .../python23.zip" ?

...

* site.py contains code which prefixes "site-packages" with both sys.prefix and sys.exec_prefix. Is this really used anywhere ? (distutils and the old Makefile.pre.in both install to sys.prefix per default)

I thought they might install extension modules in exec_prefix. But maybe it's a YAGNI.

Hmm, I've just built a Python interpreter with different prefix and exec_prefix settings: using such an interpreter lets distutils default to the exec_prefix subtree. However, Python itself does not create a site-packages directory in that tree (make install creates this directory in $(prefix)/lib/pythonX.X/ and not $(exec_prefix)/lib/pythonX.X/). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

...

...

Guido van Rossum wrote My suggestion is that the Python micro-release number be included in the path to system-packages. IOW, system-packages must exactly match the Python version number, not just the maj.min number.

+1

Excellent point. Or a micro-release should clear out the system-packages directory.

-1. That's just a bit too sudden and nasty. If this is the way to go, make a subdirectory of system-packages/site-upgrades and move the old files there (and warn the installer that they've been moved) Anthony