[Distutils] formencode as .egg in Debian ??

[Phillip J. Eby]

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".