[Python-Dev] How we can get rid of eggs for 2.6 and beyond

Fri Mar 21 23:13:32 CET 2008

On 2008年03月21日 22:21, Phillip J. Eby wrote:
> At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
>> I guess the only way to support all of these variants is
>> to use a filesystem based approach, e.g. by placing a file
>> with a special extension into some dir on sys.path.
>> The "database" logic could then scan sys.path for these
>> files, read the data and provide an interface to it.
>>>> All bdist formats would then have to include these files.
>> That's the idea behind the current version of PEP 262, yes, and I think 
> it should be kept.
>>> A separate FILES section also doesn't seem to be necessary -
>> we could just add one or more entries or the format:
>>>> CreatesDir abc/
>> CreatesFile abc/xyz1.py
>> CreatesDir abc/def/
>> CreatesFile abc/def/xyz2.py
>> CreatesFile abc/def/xyz3.py
>> CreatesFile abc/def/xyz4.ini
>> I actually think the size and hash information is good, in order to be 
> able to tell if you're looking at an original file. I'm not sure how 
> useful the permissions and uid/gid info is. I'm hoping we'll hear from 
> anybody who has a use case for that.

You're heading off in the wrong direction: we should not be trying
to rewrite RPM or InnoSetup in Python.
Anything more complicated should be left to tools which are
specifically written to manage complex software setups.
I honestly believe that most people would be happy if we just
provide these two things (and no more):
 * install a package from a local archive, a URL or PyPI
 * uninstall a package in way that doesn't break other
 installed packages
and whatever the mechanism, avoid making any undercover
changes to the Python installation such as adding
.pth files, overriding site.py, etc. - these are
not needed if the tool keeps to the simple task of
installing and uninstalling Python packages.
Examples:
python pypi.py install mypkg-1.0.tgz
python pypi.py install http://www.example.com/mypkg-1.0.tgz
python pypi.py install mypkg-1.0
python pypi.py uninstall mypkg
If there's a dependency problem, the tool should print the
list of other packages it needs. It should not try to install
things automagically.
If a package needs other modules as well, the package docs
can point the user to use e.g.
python pypi.py install mydep1-1.3 mydep2-2.3 mydep4-0.3 mypkg-1.0
instead.
Anything more complicated should be left to specialized
tools such as RPM, apt, MSI or the other such tools out
there - after all the tool should be about Python *package*
installation, not application installation.
We *don't* need the tool to:
 * support multiple versions of a package (that's just bound
 to cause problems with pickle, isinstance() etc.)
 * provide namespace hacking (is a completely separate issue
 and can be handled by the packages rather than the install
 tool)
 * support all kinds of funky version numbers (if a package
 wants to participate in the system, the author better
 make sure that the version string fits the standard format)
 * provide some form of intra-package bus interface (ie.
 "entry points" as you call them)
 * provide support for keeping whole packages in ZIP files
 (doesn't play well with C extensions, clutters up the
 sys.path, is read-only, needs special importers, etc. etc. )
 * try automatic version matching for required packages
 * download things from SourceForge or other sites with special
 download mechanisms
 * scan websites for links
 * make coffee, clean the house, send the kids to school :-)
> And of course, there are still some issues to be resolved regarding 
> requirements, package name/version stuff, etc. But we can hash those 
> out once we reach a quorum on the Distutils-SIG.

-- 
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 21 2008)
 >>> Python/Zope Consulting and Support ... http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::

 eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
 Registered at Amtsgericht Duesseldorf: HRB 46611