[Distutils] formencode as .egg in Debian ??

[Paul Moore]

On 11/23/05, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 04:53 PM 11/23/2005 +0000, Paul Moore wrote:
> >If there was a way of building a Windows installer that installed
> >packages in "egg" form, so I didn't have to use setup.py at all when
> >installing, just double-click on the installer, that would suit me.
> >This feels like what the Debian people want with their .deb format as
> >well.
>
> Right - this would hopefully be covered at some point using an .msi or .exe
> wrapper for eggs on Windows.  So far, though, you're the only person I've
> heard from about wanting this on Windows, versus the number of people who
> want it for e.g. Debian.  So I'm still considering Debian wrapper support
> as being more urgent than .msi wrapper support.

That's fair. It's quite possible that I'm unusual in my liking for
Windows installers in this context - arguing that Windows' Add/Remove
Programs applet is a good package management system is an uncommon
stance to take, certainly :-)

> My point to David was simply that egg packaging in the .egg form is more
> akin to Stow than to CPAN, so most of the flaws of CPAN are not applicable
> to them.

Sorry, I don't know what Stow is, so that doesn't clarify things to me
(but that's OK, I got your point from the previous paragraph, so if
the clarification helps David, that's enough).

> >The wording I'm using here is possibly not accurate - there seem to be
> >a confusing mix of concepts and ideas going round, with no-one having
> >a good understanding of all of them. My apologies - if there's a good
> >glossary somewhere, which explains what to call things like
> >
> >   * The executable I click on in Windows to install something
> >   * The .deb file that a Debian user downloads and installs
>
> I would call these "system packages", to distinguish them from Python
> packages.  You (and others) would like to ensure that any project you
> install is wrapped in a system package.

Gotcha. And you understand my position perfectly.

> >   * The set of files that end up in Python's site-packages
>
> A "project distribution", or just a "project" (which is a less accurate
> term but more convenient).

OK.

> >      - for a "normal" install (bdist_wininst, non-egg, whatever)
>
> This has never seemed to me to need a special term unto itself, so I don't
> have one.

I think I was more interested in it to allow me to define the
difference (egg metadata) below, so that's fine.

> >      - for an egg
>
> An egg.  :)

:-)

> >      - that comprises the difference between the above two ( :-) )
>
> Egg metadata.  An egg is just an installed project distribution that
> includes egg metadata, in one of the three possible layouts for putting
> that metadata alongside the rest of the project contents.

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.

Regarding me being the only person interested in Windows installers
which wrap eggs (which I don't dispute), 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).

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. Arguably, there should ultimately be
distutils commands for this. But what to call them? bdist_egg_wininst,
bdist_egg_deb, etc? Something else?

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)?

Paul