[Catalog-sig] [Distutils] pre-PEP : Synthesis of previous threads, and irc talks + proposals
Phillip J. Eby
pje at telecommunity.com
Tue Oct 7 22:27:40 CEST 2008
At 02:58 PM 10/7/2008 -0400, Tarek Ziadé wrote:
>On Tue, Oct 7, 2008 at 2:42 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> > At 10:07 AM 10/7/2008 -0400, Tarek Ziadé wrote:
> >> The -m feature of setuptools is nice, but it activates one version at
> >> a time, and
> >> this is globlal to Python unless each application is handling the
> >> version switch,
> >> wich is pretty heavy.
> > With or without the -m switch, scripts installed by setuptools
> will find the
> > version they are specified to use, without the user needing to do anything.
> > So, you can have a default version of an egg (used by the interpreter and
> > non-setuptools scripts), and then some non-default versions that
> are used by
> > scripts.
> > zc.buildout and virtualenv also have their own ways of accomplishing the
> > same thing, e.g., by hardcoding paths in an installed script.
>in a plain python setup,
>If foo 1.2 is the default, and a package wants use foo 1.4,
>it needs to specifically call pkg_resources.require() in the code, to
>activate it in sys.path
>before importing "foo" in the code.
You can't un-default the default, actually. If there's a default, it
can't be replaced once pkg_resources has been imported.
>Since each package can list with setuptools its dependencies with
>versions in install_requires,
>how hard would it be to automatically call the right "require()"
>calls when the package is used ?
This is already done by setuptools-generated scripts. Same for
zc.buildout and virtualenv, they just do it differently.
More information about the Catalog-SIG