Allow pip to install libraries in a directory.

[skorokithakis]

Some environments, like AppEngine, require packages to be in a specific directory. Right now, I haven't found a way to automatically download and install these. It would be fantastic if pip could download the packages and extract them into a directory specified by the user, similar to --no-install or -d, except it wouldn't just download tarballs or place them in the "build" directory, it would place them in a directory the user specified.

This could be as easy as making -d extract the tarballs or --no-install move them to a directory.

For example:

$ pip download shortuuid

Downloading/unpacking shortuuid
Downloading shortuuid-0.1.tar.gz
Running setup.py egg_info for package shortuuid

Successfully downloaded shortuuid

$ ls shortuuid
init.py

This is different from --no-install, which extracts the package in "build/" ("download" would place the module at the directory, not the entire contents of the package, the setup.py files, etc), and different from -d, which just downloads the package.

[carljm]

I think this is already almost-possible two different ways, via pip install --install-option="--home=path/" and via pip install --user with the PYTHONUSERBASE env var set. Both of those install stuff to "lib/pythonX.X/site-packages" within the target dir, not to the target dir directly, but it only takes a smidgen of scripting to move them if that's what you want.

Just making -d extract the tarballs or --no-install move them will not work; there's much more that happens in a proper installation of a Python package than just unpacking a tarball. In many cases it amounts to little more than copying a directory, but not in all cases. There are often things included in a tarball that aren't actually installed, and some packages do additional manipulations to the installed files.

I might not be opposed to a pull request for something like a --target option to the install command that would essentially be a wrapper around --install-option="--home=path/", except it would install the files directly to the target directory.

[skorokithakis]

Fantastic, I've already started work on this. Adding the extra options and aliasing to the required commands was trivial, and already works properly. However, is the assumption that I can just move all directories in "path/lib/python/" that don't end in ".egg-info" out to "path/" sound?

I am not entirely certain how pip installs packages, so I thought I should ask before assuming things that might not be correct.

[carljm]

@skorokithakis I'd actually recommend just moving everything, including the .egg-info directories. Those directories provide metadata about what's installed; their presence won't hurt anything, and there's no reason to remove that metadata.

[skorokithakis]

Great, I'll send you the pull request in a few minutes, then, thank you. My reason for removing those directories is just because of added clutter (one usually works with all the libraries installed in the working directory in GAE, for example, so those would clutter things up too much).

You are correct, though, it's trivial to just remove those if you don't need them.

[skorokithakis]

Well, everything is almost ready, except for one problem: What about libraries that already exist?

Currently, I'm using a temporary directory (from mkdtemp) to install everything in (as an argument to --home) and then I move everything to the target dir. Is the reasonable behaviour to replace anything that might already exist? If so, I'll push now.

[skorokithakis]

I have sent a push request for review, let me know if something is wrong. Overwriting existing files sounds reasonable, at least.

[carljm]

Yes, I think overwriting existing files makes sense. In the typical use case for this, the target directory would be under version control anyway, and overwriting could be useful for upgrades.

[carljm]

Fixed with merge of #447

[richburdon]

The -t option seems to break other options used with pip install.

1). with --upgrade -r requirements.txt
Error: Destination path '...' already exists (i.e., --upgrade seems to be ignored)

2). with -e git+git@github.com:.../foo.git#egg=foo
error: option --home not recognized

[webmaven]

As useful as it is, --target seems to have some problems. See Issue #1489, and the related issues linked from there.

[anentropic]

I get the following error when trying to use --target

Installing collected packages: httplib2.ca-certs-locater
  Running setup.py install for httplib2.ca-certs-locater
    error: must supply either home or prefix/exec-prefix -- not both

[zsims]

As useful as it is, --target seems to have some problems.

Fits our use-case, please don't remove it!

[eramirem]

Did you ever get to fix the incompatibility between --target and --editable options, as reported by @richburdon?
I'm running through the same difficulty.