At 11:17 PM 11/23/2005 +0000, Paul Moore wrote: >OK, I see it now. I need to reread your previous posts about the 3 >layouts, as understanding those would probably give me the remaining >pieces of the puzzle that I need.
To summarize, the layouts are .egg file (1) or directory (2), which both have a projectname-version-pyversion-platform.egg filename, and contain the project contents alongside an EGG-INFO subdirectory where the metadata lives. The third layout, originally designed for development rather than deployment, is just the project contents in an arbitrary directory, alongside a projectname.egg-info directory with the metadata in it. In setuptools 0.6a9, I will modify pkg_resources so that the .egg-info directory can also be a file (whose contents are ignored, for now) and so that its filename can also include the version, so that the PKG-INFO file can be optional in that case. This will make it easier for people wrapping non-setuptools packages as system-packaged eggs, because they will just need to "touch site-packages/projectname-version.egg-info" in order to let setuptools-using projects know that the project has been installed. In a sense, this approach sounds like a kind of "PEP 262 lite", in that it produces a basic database of installed packages, just as the .egg layout can be thought of as "PEP 262 plus", in that it offers extensible metadata as well as basic presence-and-version information. >Regarding me being the only person interested in Windows installers >which wrap eggs (which I don't dispute), Oh, I doubt you're really the only person *interested*, you're just the only person who's *asked* for it. :) > I'd be curious to know what >proportion of TurboGears (or any other egg-based project, I guess) >users are on Windows. And of them, how many have it in "live" use (as >how I'd be willing to install on a development box would differ from >what I'd do - or possibly be allowed to do - on a production box). Beats me; in my personal case, the intersection of "Windows" and "production box" is the empty set. :) >One final point - I think that naming of setup.py commands may be >confusing things here. Before eggs, the main bdist_ commands >(bdist_wininst, bdist_rpm, bdist_deb, bdist_msi, ...) created *system >packages* by your definition above. And yet, bdist_egg doesn't - it >creates an egg, which is a subtype of a project distribution. This >leads (IMO) to confusion, in that we are now seeing interest in system >packages which wrap eggs. That's a reasonable thought, except for bdist_dumb, which I think was already an exception to your otherwise-reasonable theory. > Arguably, there should ultimately be >distutils commands for this. But what to call them? bdist_egg_wininst, >bdist_egg_deb, etc? Something else? Actually, I think the better long-term approach is more likely to be tools like easy_deb that wrap easy_install. "Better" here meaning that it can save the system packager work, because it can handle finding and fetching and building in an automated way even for non-setuptools packages it has never seen before. While there are occasionally some issues with projects that have unusual customizations to the distutils, those customizations would potentially give a system packager similar troubles anyway. Conversely, if you tried to build system-packaged eggs for non-setuptools packages without easy_install, you'd have to patch their setup scripts in order to get at those hypothetical bdist_egg_foo commands. Last, but not least, system packagers vary widely in their essential build process, so it's probably easier and less fragile to let them wrap easy_install and then work from one of the three egg layouts, than to try to embed the packaging process entirely within the distutils. Of course, I haven't played around with anything but bdist_wininst and bdist_rpm, but it seems to me that at least bdist_rpm suffers from a lot of complexity by having to squeeze the process into the scope of a single distutils command, versus what it would be like if you just took an egg and turned it into an RPM. >This probably just proves that naming isn't my strong suit :-) But do >you see my point that bdist_egg is the odd one out among the bdist_ >commands (as it doesn't create a system package)? Yeah, except for the part where bdist_dumb isn't really a system packager. I always interpreted bdist as simply meaning a "binary" or "built" distribution; i.e., one that does not require a build step, just "installation". _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
