Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #197391 > unrolled thread

Re: Pip installs to unexpected place

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Pip installs to unexpected place Thomas Passin <list1@tompassin.net> - 2025-04-14 09:55 -0400
    Re: Pip installs to unexpected place rbowman <bowman@montana.com> - 2025-04-14 21:56 +0000
      Re: Pip installs to unexpected place Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-14 15:31 -0700
    Re: Pip installs to unexpected place Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-14 15:20 -0700
      Re: Pip installs to unexpected place rbowman <bowman@montana.com> - 2025-04-15 01:12 +0000
      Re: Pip installs to unexpected place Thomas Passin <list1@tompassin.net> - 2025-04-14 23:11 -0400
      Re: Pip installs to unexpected place Thomas Passin <list1@tompassin.net> - 2025-04-14 21:51 -0400

#197391 — Re: Pip installs to unexpected place

Please include the group in your response; don't just send it to me.

On 4/14/2025 5:09 AM, Jonathan Gossage wrote:
> The virtual environment was owned by the user running pip. It was not 
> owned by root. Does pip not support virtual environments that are owned 
> by a non-root user and have a multi-user secondary group? The actual 
> command was *pip install mypy flake8 sphinx*. The other packages were 
> also installed into the user .local tree and work properly for the user 
> doing the installation, but not for other members of the group that have 
> access to the virtual environment.

Pip doesn't know about the environment it runs in. It seems to me that 
you didn't active the venv before you installed using pip. So nothing 
would have gotten installed into the venv. So where is the venv that you 
set up? I usually put them into ~/venv. For example, a venv named "gf4" 
is at ~/venv/gf4.

To activate a venv, you have to source its activate script, which is in 
the venv. First you have to mark it as executable.  Then you source it -

source ~/venv/gf4/bin/activate

Now when you run python (or more likely, python3), it will find the 
venv's directories before it will find the system's or user's. You know 
the activation has been successful because the prompt changes to show 
you.  The activation applies to the terminal session in which you 
activated the venv.

> On Sun, Apr 13, 2025 at 10:11 PM Thomas Passin <list1@tompassin.net 
> <mailto:list1@tompassin.net>> wrote:
> 
>     On 4/13/2025 7:10 PM, Jonathan Gossage via Python-list wrote:
>      > I am using *Python 3.13* in a virtual environment under *Ubuntu
>     Linux 24.04*
>      > .
>      > The version of Python was compiled from source code and installed
>     with make
>      > altinstall. I attempted to use *pip* to install the *Sphinx*
>     package into
>      > the virtual environment using the command *pip install sphinx* in the
>      > virtual environment*.* I expected that *sphinx* would be
>     installed in the
>      > *site-packages* directory in the virtual environment. Instead, it was
>      > installed into the site-packages directory in
>      > */home/jonathan/.locals/lib/python3.13/site-packages* even though
>     I did not
>      > specify *--user* to the *pip install* command. Is this expected
>     behavior? I
>      > wanted Sphinx to be installed in the virtual environment so that
>     it would
>      > be accessible to all users of the virtual environment.
> 
>     If you ran the command as a user, then pip would not have root
>     privileges and could not install into the system directory. It would
>     fall back to installing into the user's tree. It usually prints a
>     message to that effect. That's standard behavior if you don't have the
>     venv activated.
> 
>     If you want to install something into a virtual environment, you
>     have to
>     activate the environment before installing the something.
> 
>     A complication could occur if the system's Python version is the
>     same as
>     the one you built. You might inadvertently run the system's binary of
>     python 3.13 instead of your own. I'm not familiar with the make
>     altinstall command but I doubt that it changes the ordinary rules for
>     invoking python and using a venv.
> 
> 
> 
> -- 
> Jonathan Gossage

[toc] | [next] | [standalone]

#197392

On Mon, 14 Apr 2025 09:55:09 -0400, Thomas Passin wrote:

> Pip doesn't know about the environment it runs in. It seems to me that
> you didn't active the venv before you installed using pip. So nothing
> would have gotten installed into the venv. So where is the venv that you
> set up? I usually put them into ~/venv. For example, a venv named "gf4"
> is at ~/venv/gf4.

Are you sure about that? activate has


VIRTUAL_ENV="/home/rbowman/work/python/weather"
export VIRTUAL_ENV

_OLD_VIRTUAL_PATH="$PATH"
PATH="$VIRTUAL_ENV/bin:$PATH"
export PATH

$PATH is modified to point to the bin directory in the venv, and it 
includes python and pip. You can use 'python3' if you really want to since 
it is there also. 

$ which pip
/home/rbowman/work/python/weather/bin/pip

'deactivate'  restores $PATH.  

I'll agree it sounds like the venv wasn't activated. 

[toc] | [prev] | [next] | [standalone]

#197394

rbowman <bowman@montana.com> writes:
> On Mon, 14 Apr 2025 09:55:09 -0400, Thomas Passin wrote:
>> Pip doesn't know about the environment it runs in. It seems to me that
>> you didn't active the venv before you installed using pip. So nothing
>> would have gotten installed into the venv. So where is the venv that you
>> set up? I usually put them into ~/venv. For example, a venv named "gf4"
>> is at ~/venv/gf4.
>
> Are you sure about that?

Sure about what?

>                          activate has
>
>
> VIRTUAL_ENV="/home/rbowman/work/python/weather"
> export VIRTUAL_ENV
[...]

The activate script is created when you create the venv (using something
like `python3 -m venv /path/to/new/venv`), and it's customized with the
location of the venv.

If Thomas creates a venv in ~/venv/gf4, that's what will appear in his
venv's active script (with the ~ expanded to the path of his home
directory).

(I'm relatively new at this.  Please let me know if I've gotten any of
the details wrong.)

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#197393

Thomas Passin <list1@tompassin.net> writes:
[...]
> To activate a venv, you have to source its activate script, which is
> in the venv. First you have to mark it as executable.  Then you source
> it -
>
> source ~/venv/gf4/bin/activate
[...]

No, you don't have to (and probably shouldn't) mark the script as
executable.

Making a script executable (chmod +x) is required before *executing* it,
but when you *source* a script (using "source" or "."), your current
shell reads it and evaluates its content.

Making the active script executable introdues the risk that you'll
accidentally execute it rather than sourcing it.  If you do that, it
will probably set up the environment in a new shell process which then
immediately terminates.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#197395

On Mon, 14 Apr 2025 15:20:13 -0700, Keith Thompson wrote:

> Making the active script executable introdues the risk that you'll
> accidentally execute it rather than sourcing it.  If you do that, it
> will probably set up the environment in a new shell process which then
> immediately terminates.

The 'activate' script starts with

# This file must be used with "source bin/activate" *from bash*
# You cannot run it directly

The csh and fish variants have similar warnings. I don't have a Windows 
box up at the moment but iirc  activate.bat or Activate.ps1 is in the 
Scripts subdirectory and you do run it directly. On Linux the python in 
bin is usually a symlink, although you can specify it to be copied with a 
parameter to venv.  Symlinks on Windows are problematic but the process is 
more or less the same.

[toc] | [prev] | [next] | [standalone]

#197396

On 4/14/2025 6:20 PM, Keith Thompson via Python-list wrote:
> Thomas Passin <list1@tompassin.net> writes:
> [...]
>> To activate a venv, you have to source its activate script, which is
>> in the venv. First you have to mark it as executable.  Then you source
>> it -
>>
>> source ~/venv/gf4/bin/activate
> [...]
> 
> No, you don't have to (and probably shouldn't) mark the script as
> executable.
> 
> Making a script executable (chmod +x) is required before *executing* it,
> but when you *source* a script (using "source" or "."), your current
> shell reads it and evaluates its content.
> 
> Making the active script executable introdues the risk that you'll
> accidentally execute it rather than sourcing it.  If you do that, it
> will probably set up the environment in a new shell process which then
> immediately terminates.

You are right, my bad.  When I went to check on what the venv prompt 
looked like after activation, I hadn't run my Linux VM for too long and 
forgot that the activate script needs to be sourced - in Windows it just 
gets run as any other script. I noticed it wasn't marked executable and 
blindly "fixed" that.  Then of course I remembered the script has to be 
sourced  - and forgot to undo the execute flag.

[toc] | [prev] | [next] | [standalone]

#197397

On 4/14/2025 6:20 PM, Keith Thompson via Python-list wrote:
> Thomas Passin <list1@tompassin.net> writes:
> [...]
>> To activate a venv, you have to source its activate script, which is
>> in the venv. First you have to mark it as executable.  Then you source
>> it -
>>
>> source ~/venv/gf4/bin/activate
> [...]
> 
> No, you don't have to (and probably shouldn't) mark the script as
> executable.
> 
> Making a script executable (chmod +x) is required before *executing* it,
> but when you *source* a script (using "source" or "."), your current
> shell reads it and evaluates its content.
> 
> Making the active script executable introdues the risk that you'll
> accidentally execute it rather than sourcing it.  If you do that, it
> will probably set up the environment in a new shell process which then
> immediately terminates.

You are right, my bad.  When I went to check on what the venv prompt 
looked like after activation, I hadn't run my Linux VM for too long and 
forgot that the activate script needs to be sourced - in Windows it just 
gets run as any other script. I noticed it wasn't marked executable and 
blindly "fixed" that.  Then of course I remembered the script has to be 
sourced  - and forgot to undo the execute flag.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web