Re: [Distutils] PEP 365 (Adding the pkg_resources module)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Guido van Rossum wrote:

On Mon, Mar 17, 2008 at 11:12 AM, Phillip J. Eby wrote:

...

At 10:53 AM 3/17/2008 -0500, Guido van Rossum wrote:

...

I don't think this should play games with scripts being overridden or whatever. If a bootstrap script is to be installed it should have a separate name. I'm not sure what the advantage is of a bootstrap script over "python -m bootstrap_module ..." though.

And -m also makes explicit:

1. that it's a Python-specific tool 2. which Python version it will apply to

Right!

...

...

The PEP suggests that other package managers also benefit. How do they benefit if the bootstrap script installs setuptools?

Because those other package managers depend, in fact, on setuptools, or at least pkg_resources... which was why the original proposal was to just include pkg_resources in the first place. :)

On how much of pkg_resources do they depend? Or is that an unanswerable question?

...

...

I'd also like to avoid the specific name "easy_install" for any of this. That's a "brand name" (and a misleading one if you ask me, but that's politics again :-).

Ok, so if someone will propose a name and API for the thing, I'll implement it. (Assuming the proposed API is sane and reasonably implementable, of course.)

Perhaps it can be called package_bootstrap? I don't know enough about the required functionality to propose an API, but here goes anyway.

Would be reasonable for it to have a command line that allows you to specify a package name, optionally a version string, and (very) optionally a server to contact (specified as an URL?). It should default to the highest non-experimental version that's applicable to the current Python version (assuming there's an easy way to determine this; I don't want it to try and download different versions until one works). It should not handle any kind of dependency management or package management administration.

It should be able to download a Python-only module or package and install it into site-packages (or perhaps elsewhere if so directed via another optional command line flag). It should support zip, tar and tar.gz/tgz files (and perhaps tar.bz2). It should simply unpack the zip/tar file using the zip or tar modules, and extract the package/module into site-packages in such a way that it can be imported directly without messing with sys.path. It should not mess with .pth files, setup.py scripts, or eggs. If the contents of the tar/zip file has a toplevel directory with version numbers in its name (e.g. Django-0.96.1) it should skip that and just use the subdirectory whose name is the "pure" package name (e.g. django).

Does this make sense? I'm happy to take push-back, this is just something I cooked up off the top of my head based on my experience with manually installing packages.

I would prefer to see it just: - Find a source distribution (the variants you specified) on the given server which matches the supplied version string, using the same semantics as the current 'pkg_resources' constraints. - Unpack the source distribution to a temp directory. - cd into that directory and use sys.executable to invoke 'setup.py install'. Any extra command-line arguments beyond those used to find the source distribution would be passed on to the 'install' command, which would allow alternate locations, etc. That makes the installation as much like a manual one as possible, and means that existing pacakges will be installable whether or not they know about setuptools, etc. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3sDr+gerLs4ltQ4RAhjWAKCbFP87mJN4UnVt0pzDs81JovVpoACdGI7A tohpRJnXah0/QnyQeYiqoYY= =9Cif -----END PGP SIGNATURE-----