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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4