Poetry: {cache-dir}/virtualenvs might not be the best place to safe virtualenvs

[hwalinga]

• [x] I have searched the issues of this repo and believe that this is not a duplicate.
• [x] I have searched the documentation and believe that my question is not covered.

Feature Request

Poetry by default saves its virtualenvs in {cache-dir}/virtualenvs which by default is ~/.cache/pypoetry/virtualenvs (Linux) and ~/Library/Caches/pypoetry/virtualenvs (MacOS). However, these folders are generally considered to be safe to be removed: Linux, MacOS

XDG also specifies to use the cache directory for non essential files. (i.e. those that are trivially recreated without user interaction.)

I report this because I emptied the cache on a server and this dropped the in the background running webserver using a poetry virtualenv, unbeknownst to me (luckily it was weekend).

So I recommend to set a different default for the virtualenv folder. If you follow XDG specifications that would probably be ~/.local/share/poetry/virtualenvs (FYI: Pipenv already uses ~/.local/share/virtualenvs), and there is probably an similar folder for MacOS.

(Default virtualenvs folder for Windows should probably be fine.)

[mrijken]

You know you can change the location, which makes it a different default obsolete?

poetry config virtualenvs.path /path/to/cache/directory/virtualenvs

or to the project / repo location:

poetry config virtualenvs.in-project true

[hwalinga]

Yes, but I found that out when it already went wrong :-)
(I wouldn't expect people to completely read the docs, especially for a package manager. So, any rm happy person can make the same mistake as me.)

But it would really be nice to have a more saner default instead. I think ~/.local/share/poetry/virtualenvs would be the perfect location (just as Pipenv does it) and for MacOS that is as it seems ~/Library/Application Support/poetry/virtualenvs or just ~/Library/poetry/virtualenvs

[DrLuke]

(I wouldn't expect people to completely read the docs, especially for a package manager. So, any rm happy person can make the same mistake as me.)

I would at least expect people to try to find out where the venv goes when deploying this to a production environment, seeing how it obviously doesn't end up in the project directory by default.

I agree however that putting them in the cache directory by default might not be the best solution, as that means that your venv could vanish seemingly random at any time you're working with it. At best it's a nuisance because you have to re-run install, at worst this could be rather devastating for someone with a slow or data-capped internet connection.

Personally I would prefer them to always end up in the project directory by default, as that means that deleting the project directory will clean up all data associated with it. If it's at a different location, like ~/.local you could collect a substantial amount of dangling venvs if you don't clean it up regularily.

[hwalinga]

I would at least expect people to try to find out where the venv goes when deploying this to a production environment, seeing how it obviously doesn't end up in the project directory by default.

I learned it the hard way, but agreed.

Personally I would prefer them to always end up in the project directory by default, as that means that deleting the project directory will clean up all data associated with it. If it's at a different location, like ~/.local you could collect a substantial amount of dangling venvs if you don't clean it up regularily.

I think that is also a very good solution, perhaps even better.

[hwalinga]

Some more "inspiration":

https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-lot-delivers-very-little/#the-break-neck-pace-of-pipenv