Re: Pip installs to unexpected place

[rbowman via Python-list]

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. 



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

Re: Pip installs to unexpected place

[rbowman via Python-list]

On Sun, 13 Apr 2025 19:10:47 -0400, Jonathan Gossage wrote:

> 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*.

How did you create the venv? Was it activated? I would use 'python -m pip 
install sphinx' but a bare pip should work.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pip installs to unexpected place

[Thomas Passin via Python-list]

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 > 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


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

Re: Pip installs to unexpected place

[Thomas Passin via Python-list]

On 4/14/2025 6:20 PM, Keith Thompson via Python-list wrote:

Thomas Passin  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.


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

Re: Pip installs to unexpected place

[Thomas Passin via Python-list]

On 4/14/2025 6:20 PM, Keith Thompson via Python-list wrote:

Thomas Passin  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.


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

Re: Pip installs to unexpected place

[Keith Thompson via Python-list]

Thomas Passin  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.thompso...@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
-- 
https://mail.python.org/mailman/listinfo/python-list