While making the script you asked for I realized
only failing to get the
~/.cargo/bin path inside the venv.
Test scripts are great for this kind of thing.
Outside of the venv I see the following paths, and
shutil.which() finds it appropriately.:
But when inside the venv the cargo path is overwritten with a the the
venv/bin path, eg:
So definitely not an issue with
shutil, but why does the venv not pick up the path?
Ah. So: how is your environment, particularly the .caro/bin path, get
set up? And how are you picking up the venv environment?
And no, I am not using any IDE, just venvs and vim.
But I, atypically I suspect, never use the
A nice thing about the python executable in the
venv/bin subdir is
that it does the correct hookups to use the venv packages all on its
own. There’s no need for
activate. The activate script seems to me
to a) fiddle your shell prompt and b) fiddle your
$PATH to put the
venv/bin at/near the front.
I hate both of those things. I want my environment to be unchanged. When
I want to use something from the venv I executable the python inside the
This isn’t actually a painful thing to do. I’ve got an alias
dev python3, which sets my 'dev" environment then runs
python3 means the
python3 from the
venv/bin. Otherwise I
get the stock python with the stock modules (in my case this is the
python from my default
By not using the venv by default my working tools are not subject to
bugs in the dev environment. Particularly since sometimes the dev env
includes developing my working tools. Always bad to break your own dev
WRT to an IDE, I was mostly thinking that a desktop-gui-invoked app will
not have picked up your environment.
Cameron Simpson firstname.lastname@example.org