[Python-Dev] Update to Python Documentation Website Request

[David Lyon]

On Wed, 29 Jul 2009 10:56:20 +1000, Nick Coghlan <ncoghlan at gmail.com>
wrote:
> The words "eggs" brings with it a whole lot more baggage than just the
> sum of the technical parts in the language core that support them
> (primarily distutils and zipimport). 

Well, in this case, (talking metaphorically) we have the ability
to roll the eggs, crack a whole in them and suck out the contents
(deal with a package in a zipped egg)

So metaphorically we could say that python can work with egg shells..

As for what's in the egg... well lets just say that it's a bit floaty..

And perphaps that is the best way for things to be for a while.

> I find it unfortunate that the name
> for the distutils metadata format contains the word "egg" because it
> implies much greater consensus around the philosophy behind eggs than
> actually exists.

I see it a different way. I thinks eggs are simple - as in like a java
bean. A simple way to move a package from one place to another. 

What seems to have gone wrong is that there is a lot of pioneering
and interconnected and interdependent technology within them. They're
an egg.. but in the past they've had little monsters that bite your
fingers when you try to put them in the pan... :-)

I think "Egg" term is very good. But maybe we are best not trying
to over-specify their contents.

Maybe we should say it has certain things (EGG_INFO, PACKAGE DATA)
as in (YOLK, WHITE) and pretty much leave it at that. If more detail
is required - rtm.

> A lot of the baggage associated with the "eggs" concept is related to
> the inherent conflict between different approaches to dependency
> management:

That's not an egg problem. That's a packaging/metadata problem.

It's the package dependency issue that's the problem. That's a distutils
problem.

> 1. Use the system package management system for everything (preferred by
> many, perhaps even most, *nix sysadmins, but not an option on Windows)

Yes, because the package dependency issues are just so great.

> 2. Create a Python specific package management system independent of the
> system package manager (an area dominated by setuptools, including both
> eggs and non-zipped package distributions)

More work needs to go into distutils. Not taking away from any existing
work - but setuptools has relied on the deficiencies of distutils to
gain a foothold.

Fix distutils (give me time to think..) and the need for setuptools and
any further fork is probably negated.

> 3. Bundle everything into a monolithic application or framework (the
> typical approach on Windows with py2exe, but also the philosophy behind
> tools like virtualenv)

Windows users are using py2exe and other products over distutils. To a
normal windows developer, distutils makes imho no sense in the way that
it goes about things now.

For example, very simple concepts like "program directories", (where
you stick the program) isn't an available option in distutils. But
it is the first thing that you need to know in a windows program.

So it's very hard to get to step 1...

> Your comments about your
> package management system suggest that it is just yet another entrant in
> category 2 and you have said nothing to allay the concerns of those that
> despise that philosophy with a passion because of the problems it causes
> them when trying to manage their systems using the first philosophy.

I'm a windows user.. I can't be in category #2..

I'm in category #1, have nothing... (except now my own tool)

> Since the Python constituency includes developers and system
> administrators that favour all 3 philosophies (and probably other
> variants that I haven't thought to describe), anything that makes it
> into the standard library will need to adequately balance the interests
> of all parties (e.g. as has occurred in the PEP 376 metadata enhancement
> discussions).

Well at least you are saying that there is some way of reconciling
all the different options...

There's an awful lot to take in, and there must be 20,000 lines of
emails for every 1 line of python code that is required to fix this
thing.

Take care

David