[Python-ideas] stdlib upgrades
Gerard Flanagan
grflanagan at gmail.com
Thu Jun 3 08:40:22 CEST 2010
Tarek Ziadé wrote:
> Hello,
>
> That's not a new idea, but I'd like to throw it here again.
>
> Some modules/packages in the stdlib are pretty isolated, which means
> that they could be upgraded with no
> harm, independently from the rest. For example the unittest package,
> or the email package.
>
> Here's an idea:
>
> 1 - add a version number in each package or module of the stdlib that
> is potentially upgradable
>
> 2 - create standalone releases of these modules/packages at PyPI, in a
> restricted area 'stdlib upgrades'
> that can be used only by core devs to upload new versions. Each
> release lists the precise
> Python versions it's compatible with.
>
Not a packaging expert, but I think in the context of a virtualenv this
all makes sense. The ability to have a pip requirements file (for
example) with
stdlib-email==2.6
stdlib-unittest==2.7
would be a useful flexibility in my view. Any given application or
library will only exercise a certain subset of stdlib after all. Also it
might give you more confidence to upgrade to a higher python if you had
this flexibility.
Whether you wanted to incorporate this in the absence of a virtualenv is
another question, I suppose.
> 4 - an upgraded package lands in a new specific site-packages
> directory and is loaded *before* the one in Lib
>
For a quick test, I added a "prioritize_site_packages" function to a
virtualenv's site.py, which just rearranged sys.path so that anything
containing the string 'site-packages' was prior to anything else. Would
this be sufficient in the general case?
More information about the Python-ideas
mailing list