[Python-Dev] Update to Python Documentation Website Request

[Jesse Noller]

On Wed, Jul 29, 2009 at 2:36 AM, David Lyon<david.lyon at preisshare.net> wrote:
> 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
>

I really do think this mail thread needs to move to disutils-sig or
python-ideas.

jesse