fix install --target on non-posix/cpython platforms.

[wickman]

For #461

[pnasrat]

Thanks for diving into this - is there an easy way to add a test for this?

[carljm]

I'm not sure a new test is needed here; the existing test for --target should cover it, it should currently fail on e.g. Windows, and this should fix it.

I'm wondering, though, why we should have to guess the install scheme. Clearly some code somewhere in distutils is actually deciding which install scheme to use when it actually performs the installation, and I'm wondering if there isn't some way we can find out which install scheme is used more directly/reliably. That's kind of vague and I won't have more time to look into it until PyCon sprints...

[wickman]

I also had hoped there'd be a nicer way, but as far as I can figure out, this is the cleanest/minimal solution. Now of course, distutils should really expose this through some API but it doesn't; that's a far bigger fish to fry.

[carljm]

I dug into this a bit, and after looking at the distutils install command, I think the problem here is that our --target uses the --home install option, where it really ought to simply use the --install-lib option directly, which entirely bypasses the install schemes and dictates directly where the lib files should be placed. This removes the need for guessing which install scheme is used.

[pnasrat]

@wickman did you have a chance to experiment with @carljm's suggestion of using --install-lib over --home?

[qwcode]

this is fixed in pip 1.2.1 via pull #628.

we have test for a --target install and it works across linux, windows, and pypy.
https://github.com/pypa/pip/blob/develop/tests/test_basic.py#L484

pip's use of --home is ok. the problem is pypy's custom "pypy" scheme breaks the home scheme (and the user scheme for that matter). windows doesn't have this problem.

my bug to pypy is here https://bugs.pypy.org/issue1272

the pip issue tracking our workaround is #629.