[Distutils] How we can get rid of eggs for 2.6 and beyond
steve at holdenweb.com
Sat Mar 22 11:25:18 CET 2008
M.-A. Lemburg wrote:
> 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.
We *do* need a way to play nice with all the various platform
installers. This would surely be welcomed by the many third parties who
now have to package Python for their platforms.
> 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.
> 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.
... unless explicitly asked to do so? It seems silly to omit this
capability when it's essentially just omitting a recursive call.
> 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
Why would this be better than using --load-dependencies?
> 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.)
Another argument for installing apps as separate components with all
dependencies. I really don't believe enough consideration has been given
as to the essential difference between these two activities.
> * provide namespace hacking (is a completely separate issue
> and can be handled by the packages rather than the install
> * 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. )
It shouldn't require special importers, though. And if the zip file
contains compiled code the read-only nature doesn't matter if the zips
> * 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 :-)
But a package that *would* do this could be immensely popular.
>> 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.
Well, I've probably been killfiled into non-existence on this list by
now, but it seems to me that we are in danger of answering the wrong
problem yet again. But that's all I have to say on this topic, so you
can all heave a sigh a relief and get on with messing it up ;-)
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
More information about the Distutils-SIG