Dear Python community.
the issue I am facing is i am not able to activate a virtual env. using Pycharm
app.
Please not the following:
1. I have a folder with a project running python/Django, named
“Production” copied in an external hard drive, the project folder was copied
from a ubun
The command to activate a venv is `source venv/bin/activate`.
---
[Visit
Topic](https://discuss.python.org/t/no-able-to-activate-a-virtual-env-on-pycharm/67551/2)
or reply to this email to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these em
thank you Alexander
I was so used to running it from powershell on windows, that I didn't use the
source command.
Thank you so much
---
[Visit
Topic](https://discuss.python.org/t/no-able-to-activate-a-virtual-env-on-pycharm/67551/3)
or reply to this email to respond.
You are receiving
Still, it boils down to: whatever command `west` executes is either not found
outside your virtual environment, or a different version exists outside it.
Path lookup is not exclusive to the shell; `subprocess.run` *also* uses path
lookup to find `command-provided-by-a-required-package`.
-
But, the [documentation says][1]:
> Furthermore, all scripts installed in the environment should be runnable
> without activating it.
My understanding is `/home/jerome/.local/pipx/venvs/west/bin/west` or `sh -c
'source /home/jerome/.local/pipx/venvs/west/bin/activate; west'` should give
the
It's expected behaviour.
To be able to run a command line tool globally, it could be installed with
pipx. Pipx'll put it in its own venv, and add the tool's executable to the
global path.
---
[Visit
Topic](https://discuss.python.org/t/venv-activate-script-changes-path-while-executing-th
I forgot to mention:
$ which west
/home/jerome/.local/bin/west
$ ls -l /home/jerome/.local/bin/west
lrwxrwxrwx 1 jerome jerome 44 Feb 22 2024 /home/jerome/.local/bin/west ->
/home/jerome/.local/pipx/venvs/west/bin/west*
The issue is not about finding the `west` command by itse
[quote="Jérôme Pouiller, post:5, topic:67580, full:true,
username:jerome-pouiller"]
But, the [documentation
says](https://docs.python.org/3/library/venv.html#how-venvs-work):
> Furthermore, all scripts installed in the environment should be runnable
> without activating it.
My understanding
hmm... so the idea is "a python package should never call a binary provided by
another package", that's it? Yet, I believe it is a common pattern.
---
[Visit
Topic](https://discuss.python.org/t/venv-activate-script-changes-path-while-executing-the-binary-doesnt/67580/8)
or reply to this e
"Should" is a strong word. Why not simply import the package and call the
entry point directly?
---
[Visit
Topic](https://discuss.python.org/t/venv-activate-script-changes-path-while-executing-the-binary-doesnt/67580/9)
or reply to this email to respond.
You are receiving this because y
No, the idea is that you write the Python code with enough information to
*identify* the external binary, given a suitable execution environment.
Ideally, you are going to execute the command by name alone, not an absolute or
relative path, and configure the (virtual) environment so that the c
I spend a bunch of time to understand why one of my python command (`west`)
didn't work as expected. Finally, I found it was because I installed my package
in a `venv` and `west` it executed commands provided by required packages. eg:
import subprocess
subprocess.run(["command-provided
Your first two examples are equivalent; activating the virtual environment is
done primarily to modify `PATH` in exactly the way you do so manually in your
second example.
What happens when you (try to) execute `west` without modifying your `PATH`
variable depends on whether a command named `
13 matches
Mail list logo
