Change default to virtualenvs.in-project = true

[wasdee]

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

Feature Request

The config virtualenvs.in-project should be defaulted to true at installation. Personally, I did this almost every single time.

On my local, codespaces, and many dockerfiles are set POETRY_VIRTUALENVS_IN_PROJECT=true. If the 80% always changes it every single time, why don't we consider make it a new default.

[MrGreenTea]

I disagree. I almost never us that config option besides for CI caching the .venv.

[thejcannon]

I can honestly live with either but I do have a preference for in-project venvs as it is much less surprising for developers that are new to Python, or just developers that are new to poetry. It also mimics other similar tools in Python (tox) and in the SW community (npm, etc...)

As long we can switch between them I think the question really is "who is the default for"?
Is it "for users who don't want to configure anything"? In that case the answer should coincide with what most users do
Is it "for developers who don't yet understand the intricacies"? In that case the answer should coincide with what they would expect.
etc...

[PetterS]

Backwards compatibility is a thing, so I think this should not be done.

[wasdee]

Backwards compatibility is a thing, so I think this should not be done.

I saw your point since users of poetry get used to explicitly set the parameter. I still see that this could be done in a backward-compatible fashion e.g. notify users about changes explicitly for a period of time when they try to override the config. , introduce this change in the major release(likely to contain some incompatible changes too)

[ghost]

For me the fact that this is not default is the biggest pain point of using poetry across various machines, especially hosts where I don't have a HOME and I don't want to have to edit my bashrc just to set the right env var.

[jaklan]

@billop but you know you can change this setting both globally and for given project and you don't have to play manually with .bashrc, right?

[ghost]

@jaklan I'm aware of both options yes; sorry looking back it seems my comment is kind of confusing. My main point was that I never want virtualenvs not to be in the project, and every time I have to setup pypoetry on a new machine I have to set the option, and the global configuration is sometimes not an option on some new hosts, which means setting it for every project.

[jaklan]

@billop what do you mean by the global configuration is sometimes not an option on some new hosts? Why are you not able to change it (especially when you can modify .bashrc)?

As a workaround you can just use the one-liner:

poetry config virtualenvs.in-project true --local && poetry [new | init | install]

BTW I also use Poetry only with in-project virtualenvs, so I support this proposal in general.

[ghost]

@jaklan I don't even remember myself, but I think I confused two different hosts, one of which periodically cannot access HOME while the other doesn't have access to my HOME (GPU cluster).

To constructively add something to the discussion: what is the advantage of the current default? I think the advantage is the usual advantage of following XDG_CACHE_HOME where files that can be deleted can be consolidated and easily kept track of. But I don't really see anything beyond that. I feel like it causes more problems than benefits and should be an option, not the default.

[wasdee]

@billop one solid benefit of is that you can easily switch between python version without a need to reinstall environments each time. since .venv could contain only 1 python version at a time. (please correct me if I am wrong)

Still in my daily python library development, I'm usually staying with a single python version and let CI/CD check other versions for me. If I have to debug then I could do a reverse of @jaklan. e.g. pyenv local 3.9.0 && poetry config virtualenvs.in-project false --local && poetry [new | init | install] case by case

[mmlynarik]

Hi, is this issue going to be resolved somehow? I personally also vote in favour of default in-project virtualenv which I consider more convenient.

[vic-k23]

Hi! I can't set virtualenvs.in-project config to true on Windows 11 with python 3.10 poetry 1.2.0: it doesn't show any error, but config stays to false, and the virtual environment has created in default cache dir. Is it an issue or am i doing something wrong?

[vic-k23]

Hi! I can't set virtualenvs.in-project config to true on Windows 11 with python 3.10 poetry 1.2.0: it doesn't show any error, but config stays to false, and the virtual environment has created in default cache dir. Is it an issue or am i doing something wrong?

It worked after restarting Windows

[neersighted]

I'm going to close this as the current behavior is stable and unlikely to change -- users who prefer this as the default can set it with poetry config virtualenvs.in-project true (as opposed to the more commonly suggested poetry config --local virtualenvs.in-project true.

For users in containers, managing your virtual environments outside of Poetry so they are at a consistent path not beholden to changes in Poetry is suggested. Poetry will re-use an already activated virtual environment instead of creating a new one -- #6398 doesn't exactly cover this, but some of the discussion and links there point to relevant patterns.

Note that poetry config --list is useful for debug to determine if the options are being applied.

[github-actions]

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.