[Python-Dev] PEP 365 (Adding the pkg_resources module)
Guido van Rossum
guido at python.org
Mon Mar 17 17:31:59 CET 2008
On Mon, Mar 17, 2008 at 11:12 AM, Phillip J. Eby <pje at telecommunity.com> 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
> >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
> >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/)
More information about the Python-Dev