Confused by virtual environments

Python Help
21

Quite trusting to add stuff to your bashrc that you don’t understand ^^

export PYENV_ROOT="$HOME/.pyenv"

this line sets the environmental variable PYENV_ROOT to what in Python is written as f"{HOME}/.pyenv" (HOME is the environenmental variable that tells you what the home directory of your user is. You can find out what it is by typing echo $HOME into a bash terminal.)

[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"

this line adds $PYENV_ROOT/bin (which is $HOME/.pyenv/bin) to your PATH environmental variable. But only if it exists and is a directory. PATH is essentially the list of places where bash looks for executables.

eval "$(pyenv init - bash)"

this line evaluates pyenv init - bash and then executes it as a bash script. Run pyenv init - bash in a bash shell to read what actually gets executed.

Same goes for eval "$(pyenv virtualenv-init -)"

22

Any env var you set in .bashrc will prevent you from setting that env var in subprocesses that run a bash script.

It usually takes a while before you get bitten by this.

23

Trusting of the install instructions from a program widely recognized and recommended in the python community, sure. It isn’t like I just picked the lines up randomly off the internet.

24

I see, why is that? As long as I was just running the script locally then the issue is moot is it not because the env will be present via bash anyway? so no need to set it in the script? My recent case in my other thread setting paths is an exception, where I am running the script on a different machine.

What about debugging this __round__ issue above? As it isn’t my script I am not sure how to narrow it down given there are no numbers in the stacktrace and this name ‘TempSensor’ is not found when grepping the folder contents so no idea where that is coming from?

EDIT: An update for the .bashrc issue is I noticed in the comments it suggested to use either .bash_profile or .profile before .bashrc, which I didn’t consider at first because I usually use .bashrc for all my shell related stuff, just out of habit. I tried moving those lines from .bashrc to .profile, as that is the only file of the other two that already existed and no more slow shell. :slight_smile: One change in behavior I noticed though is that when those lines were in .bashrc then if I opened a new session and went into the folder with the virtualenv it would automatically activate and show the (venv name) before the prompt.

With this move to .profile that didn’t happen however when I did pyenv versions to check if the pyenv localenv was active it still showed * by the virtualenv name indicating it was active. So active but without the bracketed name on the prompt. I then manually activated with source activate venv name and then the brackets appeared with the name before the prompt.

If this is just a cosmetic thing I don’t mind doing it manually, but just wondered if anything else is happening and why the difference over the previous behavior.

25

.bashrc is run before the code of your bash scripts.
That makes it impossible to define a new value for an environment variable on the command line that the .bashrc sets.

I added a line to start of my .bashrc to echo a message when its run.

Here you see me running a script that I use to start my tool venv and you will see that my .bashrc message is printed.

$ head -n2 .bashrc
echo Running .bashrc
# .bashrc
$ tool-python3
Running .bashrc
Python 3.14.3 (v3.14.3:323c59a5e34, Feb  3 2026, 11:41:37) [Clang 16.0.0 (clang-1600.0.26.6)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

Now if you never change things set in the .bashrc you may never get caught out by this gotcha.

26

.bashrc is sourced by interactive shells. It’s not clear to me why your scripts are being executed by interactive shells.

27

.bash_profile is run when you start a login shell - it does not have to be interactive. And you usually run .bashrc from your .bash_profile for sanity.

.bashrc is run for every sub-shell that is started. Running a script runs a sub-shell. Thus you see that .bashrc is run.

As I showed in the output above where .bashrc echoed Running .bashrc.
Try the experiment yourself, add echo Running .bsahrc to the top of your .bashrc and watch when you see the line echoed.

28

.bashrc is run for every sub-shell that is started. Running a script runs a sub-shell. Thus you see that .bashrc is run.

I’m truly curious as to what platform(s) this behavior reproduces for you. At least for the various GNU/Linux distributions to which I have access, I cannot get the same result. Even the bash(1) manpage indicates that /etc/bash.bashrc and ~/.bashrc are only executed if the shell is interactive. (Not to be confused with a login shell, of course.) The documentation does indicate an exception for “remote” shells, e.g. direct child processes of an sshd, but local noninteractive invocation isn’t supposed to call your .bashrc (and doesn’t do it for me at least, testing directly).

My distros do also have a quick bailout at the beginning of skeleton .bashrc files to exit immediately if the shell is discovered to be running noninteractively, but my understanding is that it’s really only there to avoid polluting the environment for remotely-executed noninteractive shell scripts/commands.

29

I’m talking about interactive use of the shell.
As you say a non-interactive shell does not run .bashrc at all.

So putting settings for environment variables in .bashrc has no effect.
Only settings for a interactive shell should be in .bashrc, like aliases.

30

Scripts are not executed by interactive shells, unless you do so explicitly with something like bash -i myscript. That’s why I’m confused as to how tool-python3sources your .bashrc.

31

What makes you think that?

If you create a shell script with a #!/bin/bash and set it chmod +x then you can run that script from an interactive shell.

For example I create a script and run it from the interactive shell:

$ cat >hi-clint
#!/usr/bin/bash
echo Hi Clint!
$ chmod +x hi-clint
$ ./hi-clint
Hi Clint!
$
32

That’s running a script from an interactive shell, not with an interactive shell.