[Distutils] The future of invoking pip

[Nathaniel Smith]

On Mon, Nov 9, 2015 at 3:28 PM, Chris Barker <chris.barker at noaa.gov> wrote:
> On Sat, Nov 7, 2015 at 3:53 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>
>> Well, the problem is that "python -m pip" isn't any better. If you
>> don't know what the current "pip" is, then chances are you don't know
>> what the current "python" is, either.
>
>
> sure you do (well, maybe not, but all you know is that when you type
> "python" you get soemthing).
>
> the problem really is when someone does:
>
> pip install some_package
>
> and it all seems to work fine
>
> then they type "python" and "import some_package" and it fails.
>
>
> This really does happend with newbies, and it really is a problem, trust me
> on that.

Here's an interesting situation to illustrate the kind of weird
problem that newbies are so good at tripping over:

$ virtualenv -p python3 test-env1
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in test-env1/bin/python3
Also creating executable in test-env1/bin/python
Installing setuptools, pip...done.
$ source test-env1/bin/activate
(test-env1)$ which python
/home/njs/test-env1/bin/python
(test-env1)$ which pip
/home/njs/test-env1/bin/pip

# So far so good... now let's create a second environment from inside the first
(test-env1)$ python -m venv test-env2
(test-env1)$ source test-env2/bin/activate
(test-env2) $ which python
/home/njs/test-env2/bin/python
(test-env2) $ which pip
/usr/bin/pip
(test-env2) $ ls test-env2/bin
activate  activate.csh  activate.fish  python@  python3@
(test-env2) $

So apparently if you use 'python -m venv' to create a new *venv* while
inside a *virtualenv*, then it seems to complete successfully but
leaves you with a venv that doesn't contain pip. At least on my
machine (up-to-date Debian testing).

I'm sure I should file a bug somewhere, but I'm not even sure where...

(Interesting fact: I also tried this but using a conda environment for
the first environment instead of virtualenv, and it failed differently
-- the 'python -m venv' call spat out an inscrutable error involving
ensurepip, and then I was left with a non-functional environment --
the test-env2/ directory exists, as does test-env2/bin/python, but
test-env2/bin/activate is missing entirely.)

This is "just a bug", but it seems fair to assume that there will
continue to exist some weird corner-case bugs in Python
packaging/distribution/environment-creation for a while yet...

-n

-- 
Nathaniel J. Smith -- http://vorpus.org