[Distutils] setuptools and extra_path

[Bob Ippolito]

On Jul 17, 2006, at 4:17 PM, Phillip J. Eby wrote:

> At 03:07 PM 7/17/2006 -0700, Bob Ippolito wrote:
>
>> On Jul 17, 2006, at 2:47 PM, Bob Ippolito wrote:
>>
>>>
>>> On Jul 17, 2006, at 2:33 PM, Phillip J. Eby wrote:
>>>
>>>> At 12:26 AM 7/17/2006 -0700, Bob Ippolito wrote:
>>>>> Is there any reason why setuptools totally ignores extra_path when
>>>>> using compatibility mode (e.g. calling .run() manually or -- 
>>>>> single-
>>>>> version-externally-managed)?
>>>>
>>>> It's probably an unintended side effect of the fact that setuptools
>>>> doesn't support extra_path.
>>>
>>> Why not support it with --single-version-externally-managed?
>>
>> And further, it should probably issue some kind of warning to let
>> people know that setuptools is ignoring this option in any scenario
>> when it is ignored... I didn't even notice until I started looking in
>> my site-packages folder to uninstall stuff.
>>
>> In this particular case I don't need --root or --record because I
>> already am tracking all of that with bdist_mpkg in a different way.
>>
>> The reason I want single-version-externally-managed behavior in the
>> first place is because I don't want to have to try and deal with
>> having the packages try and edit easy_install.pth. I suppose I could
>> have it install in an egg-dir and drop in a separate pth, but ideally
>> I wouldn't have to do anything. All I want is the old behavior plus
>> the egg_info metadata.
>
> Erm, ok, but the old behavior creates a .pth file, so you're kind  
> of confusing me here.  The other weird bit is that install_egg_info  
> would need to install to the extra_path directory.  Oy.

The old behavior creates a .pth file, but I don't have anything to do  
with it because that was part of the distutils install command. If I  
were to install as an egg I would have to write the code that creates  
this new .pth file.

> And that's not the worst of it.  "install" computes its target  
> paths during finalize_options(), so there's no way to know at that  
> point whether run() is going to be called in backward-compatibility  
> mode.  So, there doesn't seem to be a way to implement extra_path  
> for backward-compatibility mode that doesn't set the --root or -- 
> single-version-externally-managed options.
>
> If you can live with that limitation (explicitly setting one or  
> both of those options when making a super call), I can have it  
> respect extra_path.  But it's a no-go in any other circumstance,  
> I'm afraid.

I don't have any problem explicitly setting either or both of those  
options. I'm only targeting setuptools, I don't care about old  
distutils compatibility... I just want something close to the old  
behavior, for now.

-bob