rather than that custom /Users/andy/Library/Caches/pypoetry/virtualenvs directory.
Currently all virtualenv(wrapper) command dont work due to the bad virtualenv home. :(
Other than that and the other ticket (https://github.com/sdispater/poetry/issues/213) i like poetry - just switched from pipenv.
Yeah, respecting WORKON_HOME
would be great.
For now as a workaround to work with virtualenvwrapper, pipenv and with poetry I set WORKON_HOME
to poetry venvs location
If you activate the virtualenv before you use poetry, poetry will use your existing virtual environment.
Also, ~/Library/Caches/<app name>/
is the appropriate location for storing items that may be removed without damage on macOS, it's a system defined location, it's not a "custom" location.
Like @valignatev said, it would be cooler if poetry played nice with virtualenv(wrapper) and respects the already existing environment.
If there is no WORKON_HOME set, keep using that cache folder. Sounds like a good idea!
But if somebody is already using virtualenvs and has some more tools expecting new virtualenvs to be right where the existing ones are, please put em there.
This IMHO will boost the acceptance of poetry!
If you activate the virtualenv before you use poetry, poetry will use your existing virtual environment.
Reposting that doesn鈥檛 make it better.
A new virtualenv created by poetry will not work with other vitualenv tools. That鈥檚 bad! Why break an otherwise cool and working standard? It鈥檚 a much better user experience working with poetry if it just respects existing virtalenv settings.
You said:
respects the already existing environment.
It already does... it just doesn't support using WORKON_HOME
as the directory to place virtualenvs. You could make ~/Library/Caches/pypoetry/virtualenvs/
a symlink to your preferred location.
I'm not familiar with the WORKON_HOME
variable. Is it a standard used across multiple tools? Or is it exclusive to "virtualenv(wrapper)"? What is the motivation for making it the default in Poetry?
As @bertjwregeer said, Poetry already uses existing virtual environments. About the path, you can configure it with poetry config settings.virtualenvs.path $WORKON_HOME
and Poetry will create virtual environments in that directory. If, instead, you want them to be created in the project's root directory, set settings.virtualenvs.in-project
to true
.
@cauebs I know that at least virtualenvwrapper and pipenv understand $WORKON_HOME
. PyCharm might as well (not sure).
I think that I didn't know about poetry config settings.virtualenvs.path
because poetry config --list
doesn't work for me, but it solves the issue for me entirely. Will try to look into it more closely.
Thanks!
@valignatev poetry config --list
only shows the ones you have set. Did you expect it to list the available ones? Because we were discussing that option recently and maybe you were right to expect that.
Okay, i can bend poetry so that it works the way it should to not disrupt the workflow of new users.
But I thought poetry wants to be better?! And that means to not annoy users if there is no good reason to it.
Respecting WORKON_HOME by default: happy users
Using caches folder: no benefits
Hmm... Maybe there are benefits to keeping Poetry's virtual environments separated from the rest. Python tooling and its userbase are more complex than they might seem initially. Remember:
In the face of ambiguity, refuse the temptation to guess.
I think this is a discussion worth having, but I definitely wouldn't be ready to rule out the current approach.
@cauebs Yeah, I'd expect to see the available list for config --list
:) I've created separate #261 for this discussion, but you already saw it.
In case anyone's counting, I'm in the "respect WORKON_HOME
" camp.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Well i now have auto activation of the projects .venv folder active and dont need the above, so this might be closed.
With Poetry version 1.0.10 this works:
config settings.virtualenvs.path $WORKN_HOME
@cauebs I know that at least virtualenvwrapper and pipenv understand
$WORKON_HOME
. PyCharm might as well (not sure).
I think that I didn't know aboutpoetry config settings.virtualenvs.path
becausepoetry config --list
doesn't work for me, but it solves the issue for me entirely. Will try to look into it more closely.
Thanks!
Most helpful comment
In case anyone's counting, I'm in the "respect
WORKON_HOME
" camp.