At 07:31 PM 4/16/05 +0100, James Gardner wrote:
Hi Phillip,
I've got a couple of questions about Eggs, if I should be addressing it to a mailing list rather than you could you please let me know?
I imagine that the Distutils-SIG is probably a good place for discussion, so I'm cc:ing my response there.
I think Eggs is very much needed and will be extremely useful. I'd like to start organising my packages in a sensible structure for eggs. The package.eggs-info directory currently doesn't recursively include directories within eggs-info, just single files. Is this deliberate or an unfinished part of the code?
It's deliberate; nobody has presented a compelling use case for putting anything other than a handful of files in the metadata directory.
Is eggs-info designed to contain documentation, scripts and examples as well.
No; these would generally go in the package directories, where they are then retrievable via the pkg_resources module. The metadata is primarily for things that apply to the distribution as a whole, and that are needed by applications or servers to identify e.g. the role or contents of the distribution.
If so is there a convention whereby scripts can be copied to the Scripts directory of the Python installation so that they can be easily executed if an egg is actually installed?
If they're included as top-level modules, then "python -m" is sufficient to invoke them if the .egg is on sys.path or PYTHONPATH. There is no "installation" of eggs, which is at least part of their charm. :)
Couldn't a similar thing happen with documentation so a user could have one central place for documentation? Wouldn't this be useful?
It might be useful to define some kind of metadata file to identify how to find documentation files within the included packages, but I don't really see the point of putting the documentation itself in the metadata directory, aside from perhaps release notes and the like. 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.
P.S. If you want to recursively include all files in eggs-info add copy_tree to line 9 of setuptools\command\bdist_egg.py
from distutils.dir_util import create_tree, remove_tree, ensure_relative, mkpath, copy_tree
and change line 190 and surrounding lines to:
if self.egg_info:
copy_tree(self.egg_info, egg_info)
Actually, you've now convinced me that I shouldn't do this, so that people aren't tempted to cram all sorts of crazy things in there. ;)
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? PEP 262 mentions that a package database should be able to answer the following questions: * Is distribution X on a system? * What version of distribution X is installed? * Where can the new version of distribution X be found? (This can be defined as either "a home page where the user can go and find a download link", or "a place where a program can find the newest version?" Both should probably be supported.) * What files did distribution X put on my system? * What distribution did the file x/y/z.py come from? * Has anyone modified x/y/z.py locally? * What other distributions does this software need? * What Python modules does this distribution provide? A directory of .egg files could serve as a database to provide answers to all these questions. You wouldn't need to install the eggs, just have them all on the PYTHONPATH. The questions about file x/y/z.py become irrelevant if x/y/z can't be modified. 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. 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? Thanks, James
On Apr 16, 2005, at 9:08 PM, 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?
Why not solve every other problem Python has in one fell swoop? :) -bob
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.
Phillip J. Eby wrote:
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.
Fair points, I hope I haven't implied that Eggs isn't good enough as just an execution format, I said right at the start of my first email that I think Eggs is very much needed and will be extremely useful and I'm quite excited about using it for my software.
More to the point, when we have a solid execution format, it'll be easier to think about those things than it is now.
That's true too.
Let those who want particular policies write their own bloody installers, documentation generators, and autotesters. :)
I'm still tempted to have a go at writing a package manager around eggs for my software so might just give it a go for interest.. eggs have so many useful features.. I agree though that as a serious solution you would need to arbitrate a serious amount of discussion to please everyone. Thanks for your answers anyway, much appreciated. James
participants (3)
-
Bob Ippolito -
James Gardner -
Phillip J. Eby