[Distutils] How we can get rid of eggs for 2.6 and beyond

[Steve Holden]

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.
> 
> 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.
> 
... 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
> 
> instead.
> 
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
>     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)
> 
Agreed.

>   * 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 
are version-specific.

>   * 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 ;-)

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/