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