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/ _______________________________________________ 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