setuptools and extra_path
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 makes uninstallation much more painful than it would've been otherwise. -bob
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.
It makes uninstallation much more painful than it would've been otherwise.
Weren't you using --root or --record? You pretty much have to do one or the other for backward compatibility to be in effect, I believe.
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?
It makes uninstallation much more painful than it would've been otherwise.
Weren't you using --root or --record? You pretty much have to do one or the other for backward compatibility to be in effect, I believe.
No, but it's a subclass of the install command. It's caught by this in setuptools.command.install.install.run: caller = sys._getframe(2) caller_module = caller.f_globals.get('__name__','') caller_name = caller.f_code.co_name if caller_module != 'distutils.dist' or caller_name! ='run_commands': # We weren't called from the command line or setup(), so we # should run in backward-compatibility mode to support bdist_* # commands. _install.run(self) -bob
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. There are three features bdist_mpkg has that make it currently useful despite easy_install: [1] No bootstrap issue, Mac OS X ships with a GUI installer that understands .mpkg/.pkg bundles. [2] No permission issue. Mac OS X will prompt for authorization (like "sudo") when and only when it is needed [3] Installing Other Stuff. bdist_mpkg is used to install examples, documentation, headers, dependent libraries, etc. The third feature is important in a few cases, because packages like pygame have dependent libraries (the SDL frameworks), PyObjC has Xcode templates, etc. Most packages are perfectly well suited to eggs as currently specified, though. I'm not too concerned with the other two features, because those are rarely an issue and can be easily resolved with a GUI front-end to easy_install that combines ez_setup- like functionality for bootstrapping. -bob
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.
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
At 04:29 PM 7/17/2006 -0700, Bob Ippolito wrote:
On Jul 17, 2006, at 4:17 PM, Phillip J. Eby wrote:
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.
Okay, it's in the 0.7 and 0.6 SVN trunks now; please test (ez_setup.py setuptools=dev06) and let me know if it works for you.
On Jul 18, 2006, at 9:04 AM, Phillip J. Eby wrote:
At 04:29 PM 7/17/2006 -0700, Bob Ippolito wrote:
On Jul 17, 2006, at 4:17 PM, Phillip J. Eby wrote:
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.
Okay, it's in the 0.7 and 0.6 SVN trunks now; please test (ez_setup.py setuptools=dev06) and let me know if it works for you.
seems to work, thanks! -bob
At 10:11 AM 7/18/2006 -0700, Bob Ippolito wrote:
On Jul 18, 2006, at 9:04 AM, Phillip J. Eby wrote:
At 04:29 PM 7/17/2006 -0700, Bob Ippolito wrote:
On Jul 17, 2006, at 4:17 PM, Phillip J. Eby wrote:
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.
Okay, it's in the 0.7 and 0.6 SVN trunks now; please test (ez_setup.py setuptools=dev06) and let me know if it works for you.
seems to work, thanks!
-bob
Great; please check out the sdist/egg_info version thing too.
On Jul 18, 2006, at 10:42 AM, Phillip J. Eby wrote:
At 10:11 AM 7/18/2006 -0700, Bob Ippolito wrote:
On Jul 18, 2006, at 9:04 AM, Phillip J. Eby wrote:
At 04:29 PM 7/17/2006 -0700, Bob Ippolito wrote:
On Jul 17, 2006, at 4:17 PM, Phillip J. Eby wrote:
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.
Okay, it's in the 0.7 and 0.6 SVN trunks now; please test (ez_setup.py setuptools=dev06) and let me know if it works for you.
seems to work, thanks!
-bob
Great; please check out the sdist/egg_info version thing too.
Looks right, I tried both a release and dev configuration and it preserved the right metadata in setup.cfg. I have not tried a setup.cfg that had any other settings in it though. -bob
At 10:57 AM 7/18/2006 -0700, Bob Ippolito wrote:
On Jul 18, 2006, at 10:42 AM, Phillip J. Eby wrote:
At 10:11 AM 7/18/2006 -0700, Bob Ippolito wrote:
On Jul 18, 2006, at 9:04 AM, Phillip J. Eby wrote:
At 04:29 PM 7/17/2006 -0700, Bob Ippolito wrote:
On Jul 17, 2006, at 4:17 PM, Phillip J. Eby wrote:
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.
Okay, it's in the 0.7 and 0.6 SVN trunks now; please test (ez_setup.py setuptools=dev06) and let me know if it works for you.
seems to work, thanks!
-bob
Great; please check out the sdist/egg_info version thing too.
Looks right, I tried both a release and dev configuration and it preserved the right metadata in setup.cfg. I have not tried a setup.cfg that had any other settings in it though.
I've tested it with that (by building sdists of setuptools) and it works. The code that's used to edit setup.cfg is the same that's used by "setopt" and "saveopts", so it's had some prior testing for that aspect anyway. I was mainly wanting to make sure that building sdists created this way works properly. Oh, actually, the specific thing I wanted to make sure of was that on platforms with hard linking available it 1) works correctly and 2) doesn't modify the original setup.cfg. The "sdist" command can create an archive tree using hard linking, so I included some code to work around that, but it doesn't execute on Windows so I can't test it in anger, so to speak, and haven't had a moment yet to check it out on a Linux box. If you have a setup.cfg, it should delete the one in the temporary build tree and then recopy it from the source, before editing it.
On Jul 18, 2006, at 11:32 AM, Phillip J. Eby wrote:
At 10:57 AM 7/18/2006 -0700, Bob Ippolito wrote:
On Jul 18, 2006, at 10:42 AM, Phillip J. Eby wrote:
At 10:11 AM 7/18/2006 -0700, Bob Ippolito wrote:
On Jul 18, 2006, at 9:04 AM, Phillip J. Eby wrote:
At 04:29 PM 7/17/2006 -0700, Bob Ippolito wrote:
On Jul 17, 2006, at 4:17 PM, Phillip J. Eby wrote: > 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.
Okay, it's in the 0.7 and 0.6 SVN trunks now; please test (ez_setup.py setuptools=dev06) and let me know if it works for you.
seems to work, thanks!
-bob
Great; please check out the sdist/egg_info version thing too.
Looks right, I tried both a release and dev configuration and it preserved the right metadata in setup.cfg. I have not tried a setup.cfg that had any other settings in it though.
I've tested it with that (by building sdists of setuptools) and it works. The code that's used to edit setup.cfg is the same that's used by "setopt" and "saveopts", so it's had some prior testing for that aspect anyway. I was mainly wanting to make sure that building sdists created this way works properly.
Oh, actually, the specific thing I wanted to make sure of was that on platforms with hard linking available it 1) works correctly and 2) doesn't modify the original setup.cfg. The "sdist" command can create an archive tree using hard linking, so I included some code to work around that, but it doesn't execute on Windows so I can't test it in anger, so to speak, and haven't had a moment yet to check it out on a Linux box. If you have a setup.cfg, it should delete the one in the temporary build tree and then recopy it from the source, before editing it.
Mac OS X supports hard linking, and I did not see any of my setup.cfg files change while I was testing... so it seems it did what it was supposed to do without any ill side-effects. -bob
participants (2)
-
Bob Ippolito
-
Phillip J. Eby