At 02:08 AM 4/17/05 +0100, James Gardner wrote:
Phillip J. Eby wrote:
Note that eggs are primarily intended to be an *execution* format, not an installation tool or packaging system. So really the metadata is intended for programs to read and use, not for humans. Applications that need plugins often have some kind of configuration or deployment file that specifies how the accompanying code is to be used by the application, and that's what the metadata directory is for.
I hope I'm not treading on old ground here, but why not use the eggs format as a packaging system as well as an execution format?
Because I have no interest in trying to compete with existing packaging systems; it's not a wise investment of time. There are no existing execution formats for Python, however, that do what eggs can, so it's a more reasonable investment to compete in that sphere.
As far as I understand it in order to turn eggs into a really useful packaging system too, all you would need to do is write an install program to download eggs automatically (from the required dependency URLs listed or a central server) into a particular directory and have them automatically added to PYTHONPATH.
Yep. I'm just not planning to write that myself at the moment. But pkg_resources will have some functions you can give a callback to, to let you know about missing dependencies so you can invoke a downloader. The thing is, different applications will have different policies and UIs for downloading and even configuring where to download from. So, the core system isn't going to do any downloading. It will just search where it's told to search, and add things to sys.path that you ask for, and call you back when things needed to fulfill your requests are missing.
Eggs would be easy to uninstall.. just delete them. Different egg versions have different names so you could install multiple versions of the same package. The installer could then run the test suite if one existed and autogenerate documentation to a specified location. Surely it would be quite easy to use eggs as a basis for something similar to ruby gems but without the necessity of actually extracting the files.
Is there any reason why eggs aren't being thought of in this way? Is there any drawback in extending the scope to use them as a packaging system too?
Yes, I'll have more code to write then. ;) More to the point, once you step outside of the "execution format" realm, you start to get into massive disputes about what policies should exist and I really don't want to spend a lot of time arguing about that stuff. Let those who want particular policies write their own bloody installers, documentation generators, and autotesters. :) More to the point, when we have a solid execution format, it'll be easier to think about those things than it is now.