On Wed, Jul 29, 2009 at 2:36 AM, David Lyon<david.l...@preisshare.net> wrote: > On Wed, 29 Jul 2009 10:56:20 +1000, Nick Coghlan <ncogh...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
