[Python-Dev] PEP 365 (Adding the pkg_resources module)

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guido van Rossum wrote:
> 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
> 
> 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 at 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-----