At 02:58 PM 10/7/2008 -0400, Tarek Ziadé wrote:
> On Tue, Oct 7, 2008 at 2:42 PM, Phillip J. Eby <pje@[...].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. 

_______________________________________________
Catalog-SIG mailing list
Catalog-SIG@[...].org
http://mail.python.org/mailman/listinfo/catalog-sig