Re: [Distutils] formencode as .egg in Debian ??
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".
Reply to: