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. 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. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
