On Mon, Mar 17, 2008 at 11:12 AM, Phillip J. Eby <[EMAIL PROTECTED]> 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
