Open NeilGirdhar opened 1 year ago
the activated environment is the one that poetry uses when you do stuff eg in your output you can see that the activated environment is the one used by poetry shell
.
that you might or might not get an answer to which python
before typing poetry env list
is quite independent of the environments that poetry is managing for your project. The latter is what poetry env list
tells you about.
indeed your example emphasises that it would be very confusing to call that python the "shell" python since it is not the one that is used by poetry shell
.
still: merge requests welcome if you have improvements
indeed your example emphasises that it would be very confusing to call that python the "shell" python since it is not the one that is used by poetry shell.
Sorry, I'm still a bit confused here. It's poetry that is setting the shell Python to point to a different environment than the activated environment. That's why I want Poetry to tell me which Python that is.
cmm-tspD8tmv-py3.12 (Activated)
Spawning shell within /home/neil/.cache/pypoetry/virtualenvs/cmm-tspD8tmv-py3.12
these are the same thing: poetry shell
is using the activated python.
It's poetry that is setting the shell Python to point to a different environment than the activated environment.
I don't know what you mean, can you show something to support that?
these are the same thing: poetry shell is using the activated python.
Yes, that's one way to spawn a shell.
Consider:
❯ poetry env list
cmm-tspD8tmv-py3.10
cmm-tspD8tmv-py3.11
cmm-tspD8tmv-py3.12 (Activated)
❯ poetry shell
Spawning shell within /home/neil/.cache/pypoetry/virtualenvs/cmm-tspD8tmv-py3.12
❯ emulate bash -c '. /home/neil/.cache/pypoetry/virtualenvs/cmm-tspD8tmv-py3.12/bin/activate'
❯ poetry env use 3.11
Using virtualenv: /home/neil/.cache/pypoetry/virtualenvs/cmm-tspD8tmv-py3.11
❯ which python
/home/neil/.cache/pypoetry/virtualenvs/cmm-tspD8tmv-py3.12/bin/python
❯ poetry env list
cmm-tspD8tmv-py3.10
cmm-tspD8tmv-py3.11 (Activated)
cmm-tspD8tmv-py3.12
❯ poetry
❯ deactivate
❯ poetry shell
Virtual environment already activated: /home/neil/.cache/pypoetry/virtualenvs/cmm-tspD8tmv-py3.11
❯ poetry env list
cmm-tspD8tmv-py3.10
cmm-tspD8tmv-py3.11 (Activated)
cmm-tspD8tmv-py3.12
❯ poetry env use 3.12
Using virtualenv: /home/neil/.cache/pypoetry/virtualenvs/cmm-tspD8tmv-py3.12
It is very easy for the "shell environment" to diverge from the "activated environment".
There is currently no way to display that.
if you care to keep track of which environment you're currently in the usual way - and so far as I know also the default, perhaps you have deliberately undone this - is in the prompt
poetry shell
followed by deactivate
is probably broken: when you're done with a poetry shell
you should exit
or ctrl-d
. At that point it's not so much that the display is confusing as that the actual state is confusing.
to be honest I consider poetry shell
an error and would prefer to be rid of it altogether: but if you like it enough to submit improvements then, again: merge requests welcome.
poetry shell
followed bydeactivate
is probably broken: when you're done with apoetry shell
you shouldexit
orctrl-d
Sorry, but I don't think that's right. The decativate command is exactly for this.
At that point it's not so much that the display is confusing as that the actual state is confusing.
Yes, the state is confusing, which would be clarified by changing the display, which motivates my suggestions to display the current shell (if any).
The decativate command is exactly for this.
no, it isn't. The deactivate command would be suitable if you had activated the environment with source /path/to/bin/activate
. But poetry shell
is spawning a sub-shell, and that sub-shell should be exited when you are done with it.
This confusion is among the reasons that poetry shell
was a mistake in the first place (and why I never use it). Recommend just activate your virtual environments the usual way, as if poetry shell
had never existed.
The deactivate command would be suitable if you had activated the environment with source /path/to/bin/activate.
That's what I'm actually doing. I use zsh-poetry, which automatically calls activate and deactivate. I didn't want to complicate this issue though.
I didn't want to complicate this issue though.
Well that didn't work!
In that case we are back where we started:
poetry env
to describe arbitrary environmentsI'll add one more time: if there is something here that you care about, by far the most likely way of making a difference is to submit a merge request
It's confusing to me that
poetry env list
shows an activated environment that's different from the shell environment. I'm not entirely clear what activated means, but it would be nice to also show the current shell if any.My suggested output would show outputs like:
I'm also not entirely sure why the shell can be different than the activated environment.