pip3 : command not found

[Vishal Subbiah]

Hi,

So I wads trying to install some packages for python3. when I run pip3 in
terminal i receive the error
"pip3 : command not found". When looking at the path, I noticed
/usr/local/Cellar/python3/3.5.2_3 does not have pip3 in the directory while
/usr/local/Cellar/python3/3.5.2_2 does have. I am guessing this is the
issue. I tried using the get-pip.py and that didnt work either.

When I search for pip I find pip, pip2 and pip2.7 all of which are for
python 2.7.

I tried uninstalling python3 and reinstalling but that didnt work either.

I am running this on Mac OS Sierra.

Please let me know how I can fix this.

Looking forward to your response.

Regards,
Vishal Subbiah
Institute for Computational and Mathematical Engineering
Masters Student
Stanford University

[Ben Finney]

Vishal Subbiah <subbia...@gmail.com> writes:

> So I wads trying to install some packages for python3. when I run pip3
> in terminal

There is no guarantee that a command named ‘pip3’ will be installed.

Instead, you should invoke the exact Python interpreter you want – and,
by extension, the Python environment into which you want packages
installed.

$ /foo/bar/virtualenv/bin/python3 -m pip install LoremIpsum

If you already have a specific environment active and know that
‘python3’ is the correct Python interpreter from that environment, you
can omit the explicit path.

$ python3 -m pip install LoremIpsum

----

Why doesn't a command ‘pip’ or ‘pip3’ do the job? Because there's no
guarantee that will use the specific Python environment you want.

For many programs, it simply doesn't matter which Python interpreter –
or even *whether* a Python interpreter or Perl interpreter or etc. – is
the one that runs.

So most Python-implemented programs you don't need to specify which
interpreter; they know how to find it themselves, and your choice of a
different environment should not affect their operation.

But for a command that has the primary purpose of interacting with that
environment – by installing or removing packages, as Pip does – it must
obey your explicit instruction on which Python environment and
interpreter to use.

--
\ “It ain't so much the things we don't know that get us in |
`\ trouble. It's the things we know that ain't so.” —Artemus Ward |
_o__) (1834–1867), U.S. journalist |
Ben Finney

[Vishal Subbiah]

Hi,

Thanks Ben for the response. I followed your suggestion and this is what i
get:

"python3 -m pip3 install LoremIpsum
/usr/local/opt/python3/bin/python3.5: No module named pip3"

"python3 -m pip install LoremIpsum

/usr/local/opt/python3/bin/python3.5: No module named pip"

How do I fix this?

Regards,
Vishal Subbiah
Institute for Computational and Mathematical Engineering
Masters Student
Stanford University

On Sun, Oct 30, 2016 at 5:37 PM, Ben Finney <ben+p...@benfinney.id.au>
wrote:

> --
> https://mail.python.org/mailman/listinfo/python-list
>

[Chris Angelico]

On Mon, Oct 31, 2016 at 12:15 PM, Vishal Subbiah
<subbia...@gmail.com> wrote:
> "python3 -m pip install LoremIpsum
> /usr/local/opt/python3/bin/python3.5: No module named pip"
>
> How do I fix this?

This is the one that ought to work. Something's gone wrong with the
installation; as part of the install of recent Pythons, ensurepip
should be run, which will provide you with pip.

How did you install Python?

ChrisA

[Ben Finney]

Vishal Subbiah <subbia...@gmail.com> writes:

> Hi,

(Please don't top-post in responses. Instead, post your responses
interleaved with only the quoted material you are responding to
<URL:https://en.wikipedia.org/wiki/Posting_style#Interleaved_style>.)

> Thanks Ben for the response. I followed your suggestion and this is
> what i get:
>

> "python3 -m pip3 install LoremIpsum
> /usr/local/opt/python3/bin/python3.5: No module named pip3"

Do you know of anything which should provide a module named ‘pip3’? I
don't know of any distribution which makes such a module available for
import, so unless you know it's available you shouldn't expect it.

> "python3 -m pip install LoremIpsum
> /usr/local/opt/python3/bin/python3.5: No module named pip"
>
> How do I fix this?

You have revealed that the Python 3 interpreter at that path does not
have a ‘pip’ module. That's a problem, but should be easily solved
<URL:https://docs.python.org/3/library/ensurepip.html>.

--
\ “Creativity can be a social contribution, but only in so far as |
`\ society is free to use the results.” —Richard M. Stallman |
_o__) |
Ben Finney

[INADA Naoki]

> How do I fix this?

Maybe:

$ brew uninstall python3
$ brew install python3

[Jon Ribbens]

On 2016-10-31, Ben Finney <ben+p...@benfinney.id.au> wrote:
> Instead, you should invoke the exact Python interpreter you want – and,
> by extension, the Python environment into which you want packages
> installed.
>
> $ /foo/bar/virtualenv/bin/python3 -m pip install LoremIpsum

I'm slightly curious about that. /foo/bar/virtualenv/bin/python3
will just be a symbolic link to /usr/bin/python3, so how does
invoking the intepreter that way make any difference?

[Steve D'Aprano]

It doesn't. If you read the rest of Ben's post, or for that matter the
subject line of this thread, you will see he is comparing:

path/to/python3 -m pip install LoremIpsum

against:

pip3 install LoremIpsum


not a direct path to the executable versus a symbolic link to the
executable. The problem here is the "pip3" command, which does not exist.



--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[Jon Ribbens]

On 2016-10-31, Steve D'Aprano <steve+...@pearwood.info> wrote:
> On Mon, 31 Oct 2016 07:21 pm, Jon Ribbens wrote:
>> On 2016-10-31, Ben Finney <ben+p...@benfinney.id.au> wrote:
>>> Instead, you should invoke the exact Python interpreter you want – and,
>>> by extension, the Python environment into which you want packages
>>> installed.
>>>
>>> $ /foo/bar/virtualenv/bin/python3 -m pip install LoremIpsum
>>
>> I'm slightly curious about that. /foo/bar/virtualenv/bin/python3
>> will just be a symbolic link to /usr/bin/python3, so how does
>> invoking the intepreter that way make any difference?
>
> It doesn't. If you read the rest of Ben's post, or for that matter the
> subject line of this thread, you will see he is comparing:
>
> path/to/python3 -m pip install LoremIpsum
>
> against:
>
> pip3 install LoremIpsum

No, if you read the rest of Ben's post you will see that that is not
what he wrote. Maybe he meant what you are saying, I don't know, but
it isn't what he wrote. He clearly implied that you can run Python
in the context of a virtualenv by just invoking that virtualenv's
local Python without running 'activate' first. I'm curious as to
whether this is true or not (how virtualenvs work seems to be very
opaque).

[Steve D'Aprano]

On Sat, 5 Nov 2016 08:45 pm, Jon Ribbens wrote:

> On 2016-10-31, Steve D'Aprano <steve+...@pearwood.info> wrote:
>> On Mon, 31 Oct 2016 07:21 pm, Jon Ribbens wrote:
>>> On 2016-10-31, Ben Finney <ben+p...@benfinney.id.au> wrote:
>>>> Instead, you should invoke the exact Python interpreter you want – and,
>>>> by extension, the Python environment into which you want packages
>>>> installed.
>>>>
>>>> $ /foo/bar/virtualenv/bin/python3 -m pip install LoremIpsum
>>>
>>> I'm slightly curious about that. /foo/bar/virtualenv/bin/python3
>>> will just be a symbolic link to /usr/bin/python3, so how does
>>> invoking the intepreter that way make any difference?
>>
>> It doesn't. If you read the rest of Ben's post, or for that matter the
>> subject line of this thread, you will see he is comparing:
>>
>> path/to/python3 -m pip install LoremIpsum
>>
>> against:
>>
>> pip3 install LoremIpsum
>
> No, if you read the rest of Ben's post you will see that that is not
> what he wrote.

Excuse me, that is what he wrote. As you yourself quoted.

The OP said he tried to call the "pip3" command, and got an error that the
command was not found. Ben replied:

"There is no guarantee that a command named ‘pip3’ will be installed."

and then stated:

"Instead, you should invoke the exact Python interpreter you want"

The fact that (and now I'm quoting *you*, not Ben)

/foo/bar/virtualenv/bin/python3 will just be a symbolic link
to /usr/bin/python3

is irrelevant. It doesn't matter whether you call python3 via the actual
executable file, or the symbolic link. But Ben never suggested that it
would make a difference: he was contrasting calling the actual Python
interpreter wanted (Python 3, via a virtualenv) with calling a command pip3
(which does not actually exist on the OP's system).


Your implied question here:

> Maybe he meant what you are saying, I don't know, but
> it isn't what he wrote. He clearly implied that you can run Python
> in the context of a virtualenv by just invoking that virtualenv's
> local Python without running 'activate' first. I'm curious as to
> whether this is true or not (how virtualenvs work seems to be very
> opaque).

is a separate issue from the symbolic link question. Possibly you do have to
run `activate` first, I don't know, but either way this was not part of
your earlier question. You said nothing about `activate` in your earlier
post, and this is the first time you have mentioned it.

The bottom line is, I couldn't have answered your question about `activate`
because you hadn't asked it yet; you are correct that there's no difference
between calling Python via the executable and via a symlink; but Ben never
said that there was such a difference.


This thread reminds me of a scene from the Marx Bros movie "At The Circus".
Alas, Google has let me down as far as the exact quote, but it goes
something like this:

Groucho Marx, accidentally letting the big secret slip:
"The elephants will be here soon."

Society dame Margaret Dumont, taken aback:
"Elephants? What elephants?"

Groucho:
"Nobody said anything about elephants!"

[shakes head disgustedly]

"Elephants! At your age!"


I'll let you decide whether I'm Groucho or Dumont.

[Jon Ribbens]

On 2016-11-05, Steve D'Aprano <steve+...@pearwood.info> wrote:
> Your implied question here:
>
>> Maybe he meant what you are saying, I don't know, but
>> it isn't what he wrote. He clearly implied that you can run Python
>> in the context of a virtualenv by just invoking that virtualenv's
>> local Python without running 'activate' first. I'm curious as to
>> whether this is true or not (how virtualenvs work seems to be very
>> opaque).
>
> is a separate issue from the symbolic link question. Possibly you do have to
> run `activate` first, I don't know, but either way this was not part of
> your earlier question. You said nothing about `activate` in your earlier
> post, and this is the first time you have mentioned it.

I'm afraid I can only suggest that you try re-reading the subthread
again until you manage to understand it. It wasn't really that
complicated but you seem to have confused yourself greatly.

[Steve D'Aprano]

On Sun, 6 Nov 2016 02:55 am, Jon Ribbens wrote:

> I'm afraid I can only suggest that you try re-reading the subthread
> again until you manage to understand it. It wasn't really that
> complicated but you seem to have confused yourself greatly.

Are you serious?

Okay. Here's the start of the thread:

https://mail.python.org/pipermail/python-list/2016-October/715993.html

where the OP asks for help because running "pip3" causes a "command not
found" error. Just as the subject line says.

Here's Ben's reply:

https://mail.python.org/pipermail/python-list/2016-October/715994.html

where he clearly says not to rely on the "pip3" command, as it may not
exist, or may not be in the environment you expect, but to specify
precisely which Python interpreter you want to run:

[quote]

Instead, you should invoke the exact Python interpreter you want

And here's your response:

https://mail.python.org/pipermail/python-list/2016-October/716005.html

where you quote those exact same words from Ben and ask what difference it
makes as it is a symbolic link. You'll note that there is not one word
about "activate" in your post, just as I said. Instead you question why Ben
thinks there's a difference between running the sym link and running the
direct link to the executable, even though that's not what Ben said.

I can only repeat yet again: you have not understood Ben. He's not stating
that there is a difference between:

/direct/path/to/python3.x

and

/symbolic/link/to/direct/path/to/python3.x


You are right to state that they will be exactly the same[1], but wrong to
imagine that Ben said that they were different. That's not what Ben said.
He stated that there is a difference between:

/direct/path/to/python3.x -m pip ...

which specifies the precise Python environment you want to run, and:

pip3 ...

which may not exist at all, or if it exists it may not be on the PATH, or if
it is on the PATH it may not install into the Python environment that you
expect.


Oh, and ironically, you'll see that Ben anticipated and answered your
question about activate. Here's the link again, to save you scrolling up:

https://mail.python.org/pipermail/python-list/2016-October/715994.html

where he says:

If you already have a specific environment active and know that
‘python3’ is the correct Python interpreter from that environment,
you can omit the explicit path.

The implication is that the answer to your question is Yes, you can run

Python in the context of a virtualenv by just invoking that virtualenv's

local Python without running 'activate' first. Is Ben correct? The
virtualenv documentation confirms that Ben is right:

If you directly run a script or the python interpreter from the
virtualenv’s bin/ directory (e.g. path/to/ENV/bin/pip or
/path/to/ENV/bin/python-script.py) there’s no need for activation.

https://virtualenv.pypa.io/en/stable/userguide/#activate-script






[1] Technically, the application being run may invoke different behaviour
depending on the name it was invoked by. Some editors do that, e.g.
the "joe" editor. But I don't believe Python does anything like this.

http://joe-editor.sourceforge.net/

[Chris Angelico]

On Sun, Nov 6, 2016 at 3:53 AM, Steve D'Aprano
<steve+...@pearwood.info> wrote:
> [1] Technically, the application being run may invoke different behaviour
> depending on the name it was invoked by. Some editors do that, e.g.
> the "joe" editor. But I don't believe Python does anything like this.
>
> http://joe-editor.sourceforge.net/

And quite a few other examples, too - some versions of bash will act
in a more sh-compatible way if invoked as /bin/sh, thus allowing one
to be a link to the other.

Here's how I'm probing Python for this behaviour:

1) Brand new venv

rosuav@sikorsky:~/tmp$ python3 -m venv env

2) With venv active:

(env) rosuav@sikorsky:~/tmp$ python3
Python 3.7.0a0 (default:72e64fc8746b+, Oct 28 2016, 12:35:28)
[GCC 6.2.0 20161010] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.executable
'/home/rosuav/tmp/env/bin/python3'
>>> sys.path
['', '/usr/local/lib/python37.zip', '/usr/local/lib/python3.7',
'/usr/local/lib/python3.7/lib-dynload',
'/home/rosuav/tmp/env/lib/python3.7/site-packages']

3) With venv not active:

rosuav@sikorsky:~$ python3
Python 3.7.0a0 (default:72e64fc8746b+, Oct 28 2016, 12:35:28)
[GCC 6.2.0 20161010] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.executable
'/usr/local/bin/python3'
>>> sys.path
['', '/usr/local/lib/python37.zip', '/usr/local/lib/python3.7',
'/usr/local/lib/python3.7/lib-dynload',
'/home/rosuav/.local/lib/python3.7/site-packages',
'/usr/local/lib/python3.7/site-packages']

4) Proof that it really is a symlink:

(env) rosuav@sikorsky:~/tmp$ ll env/bin
total 32
-rw-r--r-- 1 rosuav rosuav 2134 Nov 6 05:57 activate
-rw-r--r-- 1 rosuav rosuav 1250 Nov 6 05:57 activate.csh
-rw-r--r-- 1 rosuav rosuav 2414 Nov 6 05:57 activate.fish
-rwxr-xr-x 1 rosuav rosuav 249 Nov 6 05:57 easy_install
-rwxr-xr-x 1 rosuav rosuav 249 Nov 6 05:57 easy_install-3.7
-rwxr-xr-x 1 rosuav rosuav 221 Nov 6 05:57 pip
-rwxr-xr-x 1 rosuav rosuav 221 Nov 6 05:57 pip3
-rwxr-xr-x 1 rosuav rosuav 221 Nov 6 05:57 pip3.7
lrwxrwxrwx 1 rosuav rosuav 7 Nov 6 05:57 python -> python3
lrwxrwxrwx 1 rosuav rosuav 22 Nov 6 05:57 python3 -> /usr/local/bin/python3

5) Moment of truth:

rosuav@sikorsky:~$ tmp/env/bin/python3
Python 3.7.0a0 (default:72e64fc8746b+, Oct 28 2016, 12:35:28)
[GCC 6.2.0 20161010] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.executable
'/home/rosuav/tmp/env/bin/python3'
>>> sys.path
['', '/usr/local/lib/python37.zip', '/usr/local/lib/python3.7',
'/usr/local/lib/python3.7/lib-dynload',
'/home/rosuav/tmp/env/lib/python3.7/site-packages']


So it looks like Python actually *does* take notice of the executable
path. This is presumably to allow shebangs to be created the easy way
("#!" + sys.executable) and to always represent the correct Python,
even if you had a venv active.

Now, that said, everything about the previous thread *here* was still
true. People weren't talking about symlinks. But this does mean that
(at least on recent Pythons) running Python from within a venv will
implicitly activate it. (And since the pip* files in that directory
use exactly that shebang, this is also true of running
"tmp/env/bin/pip install spam".)

I'll leave it to someone else to test the older 'virtualenv' module,
as I don't have it installed here.

ChrisA

[Jon Ribbens]

On 2016-11-05, Steve D'Aprano <steve+...@pearwood.info> wrote:

> On Sun, 6 Nov 2016 02:55 am, Jon Ribbens wrote:
>> I'm afraid I can only suggest that you try re-reading the subthread
>> again until you manage to understand it. It wasn't really that
>> complicated but you seem to have confused yourself greatly.
>
> Are you serious?

Yes. You haven't understood the thread, and I don't know how to
explain it any simpler, so I'm afraid all I can suggest is that
you re-read what was already written.

> I can only repeat yet again: you have not understood Ben.

You're still wrong no matter how many times you repeat yourself.
I've understood him, you have understood neither him nor me.
You've got hung up on the pip3 issue which is blinding you to
the other implications of Ben's answer.

Threads can and usually do diverge to a greater or lesser degree. Just
because a post is a follow-up in a thread doesn't mean that post is
entirely and solely about the original topic of that thread. Try
dropping your preconceptions and reading the sub-thread again from the
post before my first post without making false assumptions and while
bearing in mind that I am asking a question that is tangential to the
original question rather than directly descended from it.

> The implication is that the answer to your question is Yes, you can run
> Python in the context of a virtualenv by just invoking that virtualenv's
> local Python without running 'activate' first.

So you were wrong earlier when you said you couldn't do that?

You're spending an awful lot of effort being pointlessly argumentative
about who has or hasn't understood what while avoiding addressing the
actual perfectly simple question - if running Python directly from a
venv path is equivalent to running 'activate' then Python, how does it
know that it's in a venv? (Yes, I know it can sort-of work out where
it's run from using argv[0] but how does it know it's *in a venv*?)

[Ben Finney]

Steve D'Aprano <steve+...@pearwood.info> writes:

> Oh, and ironically, you'll see that Ben anticipated and answered your
> question about activate. Here's the link again, to save you scrolling up:
>
> https://mail.python.org/pipermail/python-list/2016-October/715994.html
>
> where he says:
>
> If you already have a specific environment active and know that
> ‘python3’ is the correct Python interpreter from that environment,
> you can omit the explicit path.

That's what I said, and Steven is reading its meaning correctly.

--
\ “You can be a theist, and you can be a skeptic. But if you're |
`\ both, you're not very good at one of them.” —Dave Silverman, |
_o__) 2011-11-19 |
Ben Finney

[Steve D'Aprano]

On Sun, 6 Nov 2016 07:55 am, Jon Ribbens wrote:

>> The implication is that the answer to your question is Yes, you can run
>> Python in the context of a virtualenv by just invoking that virtualenv's
>> local Python without running 'activate' first.
>
> So you were wrong earlier when you said you couldn't do that?

I'm happy to admit it when I have made a mistake, but this isn't one of

those times. I didn't say it couldn't be done, I initially said:

"Possibly you do have to run `activate` first, I don't know"

but you already know that, since you can read just as well as I can.

> You're still wrong no matter how many times you repeat yourself.
> I've understood him, you have understood neither him nor me.

[...]

> You're spending an awful lot of effort being pointlessly argumentative
> about who has or hasn't understood what while avoiding addressing the
> actual perfectly simple question - if running Python directly from a
> venv path is equivalent to running 'activate' then Python, how does it
> know that it's in a venv?

And now you change your story for the second time.

As I said, I'm happy to admit when I am wrong. I was wrong to think you were
discussing this in good faith. You're clearly not: you keep changing your
story, keep insisting that the question you have asked is different from
what you previously wrong.

First you asked about symlinks, misunderstanding what Ben wrote; then you
denied you asked that and insisted you really asked about activate (despite
not having even mentioned activate); and now you're inventing a new
question, "how does it know it is in a venv?".

Life is too short to waste time in a pointless discussion with trolls who
argue in bad faith, as you are doing. Welcome to my kill-file.

*plonk*

[Jon Ribbens]

On 2016-11-06, Steve D'Aprano <steve+...@pearwood.info> wrote:
> *plonk*

Thank feck for that, I was beginning to think he'd never shut up.

I don't suppose anyone else more constructive and informed actually
knows the answer to my rather simple question of how Python knows
it's in a venv? ;-)

[Chris Angelico]

On Sun, Nov 6, 2016 at 3:03 PM, Jon Ribbens <jon+u...@unequivocal.eu> wrote:
> I don't suppose anyone else more constructive and informed actually
> knows the answer to my rather simple question of how Python knows
> it's in a venv? ;-)

Two ways.

1) Normally, you 'activate' the venv by sourcing a script into your
shell. This modifies $PATH, $PYTHONHOME, and I think a couple of other
environment variables.

2) If Python notices that its executable comes from a venv, it uses it.

(I wasn't aware of #2 until this thread.)

Generally, you type "python" or "python3" and the shell searches
$PATH. If you have a venv active, it'll find the one there before it
finds the system one.

ChrisA

[Jon Ribbens]

On 2016-11-06, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Nov 6, 2016 at 3:03 PM, Jon Ribbens <jon+u...@unequivocal.eu> wrote:
>> I don't suppose anyone else more constructive and informed actually
>> knows the answer to my rather simple question of how Python knows
>> it's in a venv? ;-)
>
> Two ways.
>
> 1) Normally, you 'activate' the venv by sourcing a script into your
> shell. This modifies $PATH, $PYTHONHOME, and I think a couple of other
> environment variables.

It sets VIRTUAL_ENV, adds the virtualenv's bin directory to PATH,
and *unsets* PYTHONHOME if set. That's it (modulo storing old values
of variables and updating PS1 which is presumably just cosmetic).

> 2) If Python notices that its executable comes from a venv, it uses it.

Yes. My question is *how does it notice*?

[Ben Finney]

Jon Ribbens <jon+u...@unequivocal.eu> writes:

> On 2016-11-06, Steve D'Aprano <steve+...@pearwood.info> wrote:
> > *plonk*
>
> Thank feck for that, I was beginning to think he'd never shut up.

Really? I didn't see a single message from Steven that wasn't solicited
by an assertion from you that needed response.

If your concept of “won't shut up” includes “responds to me when I
demand he acknowledge my position is correct”, then it seems clear the
problem has a different solution.

--
\ “Prayer must never be answered: if it is, it ceases to be |
`\ prayer and becomes correspondence.” —Oscar Wilde, _The Epigrams |
_o__) of Oscar Wilde_, 1952 |
Ben Finney

[Jon Ribbens]

On 2016-11-06, Ben Finney <ben+p...@benfinney.id.au> wrote:
> Jon Ribbens <jon+u...@unequivocal.eu> writes:
>> On 2016-11-06, Steve D'Aprano <steve+...@pearwood.info> wrote:
>> > *plonk*
>>
>> Thank feck for that, I was beginning to think he'd never shut up.
>
> Really? I didn't see a single message from Steven that wasn't solicited
> by an assertion from you that needed response.
>
> If your concept of “won't shut up” includes “responds to me when I
> demand he acknowledge my position is correct”, then it seems clear the
> problem has a different solution.

He consistently misunderstood almost everything I said (which is
a pattern of behaviour he seems to have, i.e. heroically
misunderstanding people so he can argue with them), lied about
what I had said, lied about what he had said, lied about me "not
arguing in good faith", was rude and insulting, and studiously avoided
the actual interesting and useful topic in favour of a stupid and
pointless flamewar about his misunderstanding of my original question.

He clearly didn't know the answer to the question nor did he have any
interest in dicussing it in a civilised manner with a view to
discovering the answer, he just wants an argument. So yes, I view him
bowing out of the conversation as an unmitigated blessing.

[Ben Finney]

Jon Ribbens <jon+u...@unequivocal.eu> writes:

> He […] lied about me "not arguing in good faith"

I find you to be not arguing in good faith; if you consistently engage
someone in a manner that requires response, that's not consistent with
also “wondering when they'd shut up”.

> So yes, I view him bowing out of the conversation as an unmitigated
> blessing.

You could have disengaged at any time, so I don't find your statement
believable.

--
\ “Firmness in decision is often merely a form of stupidity. It |
`\ indicates an inability to think the same thing out twice.” |
_o__) —Henry L. Mencken |
Ben Finney

[Jon Ribbens]

On 2016-11-06, Ben Finney <ben+p...@benfinney.id.au> wrote:

> Jon Ribbens <jon+u...@unequivocal.eu> writes:
>
>> He […] lied about me "not arguing in good faith"
>
> I find you to be not arguing in good faith;

I find that to be particularly pompous of you. I am arguing in good
faith regardless of your misguided opinion.

I wasn't actually even trying to argue at all, I simply had
a question, which Steven successfully derailed into a stupid argument
as to whether he knew better than me what question I was asking.

>> So yes, I view him bowing out of the conversation as an unmitigated
>> blessing.
>
> You could have disengaged at any time, so I don't find your statement
> believable.

I plead guilty to an excess of optimism that I could persuade him to
start discussing the actual topic. I had actually reached the end of
my optimism in that regard and the last post I had made to him was
the last one in which I had intended to bother trying to get through
to him.

[Chris Angelico]

On Sun, Nov 6, 2016 at 4:27 PM, Jon Ribbens <jon+u...@unequivocal.eu> wrote:
>> 2) If Python notices that its executable comes from a venv, it uses it.
>
> Yes. My question is *how does it notice*?

I could answer this question, but since you don't appear to be
following the thread properly, I'll point out that it's already been
said up above. Go read it.

ChrisA

[Michael Torrie]

On 11/05/2016 11:27 PM, Jon Ribbens wrote:
>> 2) If Python notices that its executable comes from a venv, it uses it.
>
> Yes. My question is *how does it notice*?

I'm guessing that it notices by examining the path it was launched from
and looks for virtual environment files relative to that path.

Here's what a random site said about this (I didn't search long enough
to find the official documentation on python.org):

"When Python is starting up, it looks at the path of its binary (which,
in a virtual environment, is actually just a copy of, or symlink to,
your system’s Python binary). It then sets the location of sys.prefix
and sys.exec_prefix based on this location, omitting the “bin” portion
of the path."

This is actually a common idiom in the unix world. For example, busybox
works on this principle. You link the busybox executable and call it,
say, "cat" and when involved, busybox looks to see how what path it was
launched via and then behaves accordingly.

[Jon Ribbens]

On 2016-11-06, Chris Angelico <ros...@gmail.com> wrote:

That's not particularly helpful. I have read the entire thread and
the question does not appear to have been answered. Could you at
least provide the date/date/from (if not a Message-ID) of the post
you are talking about please?

[Jon Ribbens]

On 2016-11-06, Michael Torrie <tor...@gmail.com> wrote:
> I'm guessing that it notices by examining the path it was launched from
> and looks for virtual environment files relative to that path.

Indeed, the mysterious thing is what are "virtual environment files"?
The official docs say "A venv is a directory tree which contains
Python executable files and other files which indicate that it is a
venv." but don't explain what they mean by "other files".

> Here's what a random site said about this (I didn't search long enough
> to find the official documentation on python.org):
>
> "When Python is starting up, it looks at the path of its binary (which,
> in a virtual environment, is actually just a copy of, or symlink to,
> your system’s Python binary). It then sets the location of sys.prefix
> and sys.exec_prefix based on this location, omitting the “bin” portion
> of the path."

Aha! This is progress. OK, I've done some more investigation and it
looks like the above description is not exactly accurate.

The magic is actually all in site.py by the looks of it. This looks
at argv[0] (effectively - it's actually using sys.executable) and
then looks for ./pyvenv.cfg and ../pyvenv.cfg relative to that file.
Only if one of those files exists does it then set sys.prefix to ..
relative to sys.executable and then sys.path is set using various
hard-coded paths relative to sys.prefix.

So the answer to my original question is that Python knows it's in a
venv "if there exists a file called pyvenv.cfg in the same directory
as or the parent directory of the python exeuctable".

It also appears that this feature was added in Python 3.3, so being
able to run the venv python directly presumably only works on that
version and later.