At 10:40 AM 8/11/2005 +0100, Paul Moore wrote:
there's a transitional problem with bdist_wininst installers, which needs some thinking about (and no, easy_install's "convert a wininst installer to an egg" feature isn't an answer - it loses things like cx_Oracle's documentation,
FYI, if there's a source distribution, the new --editable option (in CVS) allows you to download and extract the source for editing, without building it or anything.
and I suspect that it breaks horribly for pywin32, which uses a postinstall script).
Hm. It's true that I haven't done anything to handle postinstall scripts; but I was under the impression that pywin32 self-registers when you try to use it. I'll have to look into that. I could probably actually add postinstall hooks to EasyInstall, except that it sort of goes against the concept of eggs being a "zero install" format. It's worth thinking about/investigating though.
As this issue is transitional only, it's not the end of the world, as long as eggs really do become the package distribution medium of choice for Python. I'd like to see some sign that eggs are making inroads against bdist_wininst, first, though.
That's not going to happen real soon; only a relatively tiny number of people even know eggs exist, and as long as they have a reasonably-usable bdist_wininst available then it's certainly a valid choice to just distribute that, thereby pleasing EasyInstall users and non-users alike.
So unless you are building packages with C extensions having complex build requirements, you'll get no incentives from me - the source package is fine. But I'll use it to build Windows installers, and never bother with eggs.
Some packages of course may be eventually only be distributed as eggs. For example, I'm switching all of my win32 binary distributions to eggs, which means you'll have to compile from source if you want a bdist_wininst. But I'm likely to be in the minority for some time to come. Transitions like this don't happen overnight, especially not based on an 0.6 alpha infrastructure. :)
(Is there ever going to be a situation where code *won't work" unless run from an egg?
Plugins, definitely. And over time, the definition of what constitutes a "plugin" is likely to be ever-expanding. For example, setuptools now supports plugins to add distutils commands, setup() arguments, and so on. The *only* way to leverage these features is with an egg, even if it's a "development-mode" egg.
I can see that being an issue, unless there's a way availabe to wrap eggs in Windows installers, RPMs, debs, etc
There is in principle, but the respective bdist commands would need some updating in order to work that way. Currently, you'd have to run EasyInstall first, and then package the resulting egg file or directory tree. This is an area that needs some actual tool development, to produce some scripts like 'egg2rpm', 'egg2wininst', etc. Or better yet, setuptools should probably grow replacement bdist commands, although these could also be distributed as extension eggs at first.
Agreed, and I understand the benefits. But I don't have the experience to understand the trade-offs and/or risks, so I have to be very cautious in what I promise. (For example, if I code an "uninstall" command, and someone runs it on a development install, does that delete all of that person's working code? How can I make sure that doesn't happen without breaking the "normal" uninstall functionality?
Don't delete anything that's not in the directory or directories your tool is managing. Development installations are outside the normal site-packages area, and deleting the '.egg-link' file from the site-packages directory "uninstalls" it.