On Mon, Mar 17, 2008 at 11:12 AM, Phillip J. Eby
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. -- --Guido van Rossum (home page: http://www.python.org/~guido/)