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/