[PEAK] dumb question about easy_install

[Michael Bayer]

OK, so yah i see this is the change in 0.6a11 that does a more  
aggressive form of dealing with conflicts.

Ive tried the "develop" command below, and while Im sure I'll get it  
to work soon, my first three attempts have returned error messages or  
just not worked.

This is in contrast to PYTHONPATH, which had a very simple and  
obvious operation (and also consistent with every other language  
environment's behavior).  PYTHONPATH's behavior now diverges from  
whats documented in all the python books and websites when anything  
setuptools-related has been installed, and the alternative is now  
significantly more tedious and complicated (and also will totally hit  
newbies by surprise).

Why cant we retain "classic" behavior for at least paths that are  
explicitly in PYTHONPATH ?  or at least have some other variable like  
PEAKPATH or something ?   this new behavior seems to be not in the  
spirit of simple and transparent behavior for an installer tool.

i.e.:

import sys; sys.__plen = len(sys.path)
.. list of modules ...
import os; import sys; new=sys.path[sys.__plen:]; del sys.path 
[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new;  
sys.__egginsert = p+len(new); [sys.path.insert(0, x) for x in  
os.environ.get('PYTHONPATH', '').split(os.pathsep)];



On Jun 28, 2006, at 12:22 PM, Phillip J. Eby wrote:

> At 11:52 AM 6/28/2006 -0400, Michael Bayer wrote:
>> I noticed after upgrading setuptools recently that PYTHONPATH usage
>> has gotten more complicated.  I.e., if I open a shell and just
>> arbitrarily set PYTHONPATH to a directory where i have some code
>> somewhere, the "official" version of the package in site-packages
>> insists on being used, as though PYTHONPATH doesnt exist.  to get it
>> to work, i had to blow away the package in the site-packages/easy-  
>> install.pth file....not such a terrific solution.
>>
>> then I noticed in the docs that there is a "traditional"  
>> pythonpath- based installation method.  but this seems to be more  
>> about, "you
>> want to install your package in a PYTHONPATH directory instead of
>> site-packages".  which is not what im looking for.
>>
>> i want setuptools to put things in site-packages like it always does;
>> but i want to be able to occasionally override the existence of the
>> package in the normal way by setting PYTHONPATH to some local
>> directory somewhere.   just like we do in java with CLASSPATH, or in
>> a unix distro with LD_LIBRARY_PATH, or perl with PERL5LIB...is this
>> no longer possible with setuptools?
>
> The issue is that setuptools-installed packages take precedence  
> over any other form of packages, in order to prevent package  
> version conflicts.  For something on PYTHONPATH to override a site- 
> packages egg, it has to be a PYTHONPATH egg.
>
> If you want to put a source directory on PYTHONPATH, you should use  
> "setup.py develop" with setuptools; this will put a .egg-link file  
> in the target directory that points to your development source  
> code, e.g.:
>
> cd /my/source
> PYTHONPATH=/some/dir python setup.py develop -d /some/dir
> PYTHONPATH=/some/dir python
>
>
>> or is this just a bug ?
>
> No, it's as-designed, but it's probably not as well-documented as  
> it should be.
>
> Note also that you can avoid this behavior by using -m with  
> easy_install, and this will not put the packages on sys.path by  
> default, so PYTHONPATH will take precedence.  However, packages  
> installed with -m won't be importable unless you  
> pkg_resources.require() them in the interpreter.  (Scripts  
> installed via easy_install will work correctly, however, whether  
> you use -m or not.)
>
> _______________________________________________
> PEAK mailing list
> PEAK at eby-sarna.com
> http://www.eby-sarna.com/mailman/listinfo/peak