Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please use the default virtualenv directory #214

Closed
kakulukia opened this issue Jun 14, 2018 · 17 comments
Closed

Please use the default virtualenv directory #214

kakulukia opened this issue Jun 14, 2018 · 17 comments

Comments

@kakulukia
Copy link

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 (#213) i like poetry - just switched from pipenv.

@valignatev
Copy link
Contributor

valignatev commented Jun 17, 2018

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

@digitalresistor
Copy link
Contributor

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.

@kakulukia
Copy link
Author

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!

@digitalresistor
Copy link
Contributor

If you activate the virtualenv before you use poetry, poetry will use your existing virtual environment.

@kakulukia
Copy link
Author

Reposting that doesn’t make it better.

A new virtualenv created by poetry will not work with other vitualenv tools. That’s bad! Why break an otherwise cool and working standard? It’s a much better user experience working with poetry if it just respects existing virtalenv settings.

@digitalresistor
Copy link
Contributor

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.

@cauebs
Copy link
Contributor

cauebs commented Jun 27, 2018

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.

@valignatev
Copy link
Contributor

@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!

@cauebs
Copy link
Contributor

cauebs commented Jun 27, 2018

@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.

@kakulukia
Copy link
Author

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

@cauebs
Copy link
Contributor

cauebs commented Jun 27, 2018

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.

@valignatev
Copy link
Contributor

@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.

@garyo
Copy link

garyo commented Dec 14, 2018

In case anyone's counting, I'm in the "respect WORKON_HOME" camp.

@stale
Copy link

stale bot commented Nov 13, 2019

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.

@stale stale bot added the stale label Nov 13, 2019
@kakulukia
Copy link
Author

Well i now have auto activation of the projects .venv folder active and dont need the above, so this might be closed.

@stale stale bot removed the stale label Nov 13, 2019
@nonZero
Copy link

nonZero commented Dec 6, 2020

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 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!

dimbleby pushed a commit to dimbleby/poetry that referenced this issue Apr 21, 2022
Copy link

github-actions bot commented Mar 2, 2024

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants