[Distutils] formencode as .egg in Debian ??
Phillip J. Eby
pje at telecommunity.com
Thu Nov 24 00:42:32 CET 2005
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".
More information about the Distutils-SIG
mailing list