# PEP 704 - Require virtual environments by default for package installers **URL:** \ **Category:** Packaging\ **Created:** [January 16, 2023, 11:38pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846 "2023-01-16T23:38:31Z")\ **Posts on this page:** 20\ **Page:** 8
**Author:** ![johnthagen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/johnthagen/32/3780_2.png) [@johnthagen](https://discuss.python.org/u/johnthagen)\ **Post date:** [March 14, 2023, 12:35pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/145 "2023-03-14T12:35:08Z")
If the community is going to standardize on `.venv` as the default name, we should ask `virtualenv` to update their docs. They currently use `venv` as the default: - [User Guide - virtualenv](https://virtualenv.pypa.io/en/latest/user_guide.html) Another place I’ve seen `venv` instead of `.venv` is we could also ask PyCharm to change their default (when it’s not already using a workflow tool such as Poetry): - [Configure a virtual environment | PyCharm Documentation](https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html) I suspect PyCharm would do this if there was an accepted PEP that decreed this. ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [March 14, 2023, 12:52pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/146 "2023-03-14T12:52:24Z")
Why not just raise a request/PR asking them to change? If they refuse, asking them what it would take to change their minds would be a useful way of determining what needs to happen next. ---
**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\ **Post date:** [March 14, 2023, 1:25pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/147 "2023-03-14T13:25:58Z")
> [@johnthagen](#): > > If the community is going to standardize on `.venv` as the default name, we should ask `virtualenv` to update their docs. They currently use `venv` as the default: @bernatgabor ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [March 14, 2023, 6:39pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/148 "2023-03-14T18:39:42Z")
> [@petersuter](#): > > Could it instead default to behave like `python -m venv .venv`? (If that is / will be the recommendation.) Possibly/probably, but we would need to get `.venv` written down as the “official” recommendation first. ---
**Author:** ![PythonCHB](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pythonchb/32/2551_2.png) [@PythonCHB](https://discuss.python.org/u/PythonCHB)\ **Post date:** [March 15, 2023, 5:37am UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/149 "2023-03-15T05:37:29Z")
I wonder about `.venv` for newbies. “dotfiles”, are (I"m pretty sure) hidden by default on all \*nix and Macs, and shown by default on Windows. Most \*nix users will expect this, but Mac users might get pretty confused. Newbies have enough trouble with Windows hiding the filename extension by default ☹ ---
**Author:** ![BrenBarn](https://avatars.discourse-cdn.com/v4/letter/b/74df32/32.png) [@BrenBarn](https://discuss.python.org/u/BrenBarn)\ **Post date:** [March 15, 2023, 6:24am UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/150 "2023-03-15T06:24:20Z")
> [@PythonCHB](#): > > I wonder about `.venv` for newbies. Yes, and for Windows users. The “dotfile” convention is very unixy-centric. I don’t really use venv so I’m not sure, but it does sound like `.venv` is kind of standard already. ---
**Author:** ![Saphyel](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/saphyel/32/8344_2.png) [@Saphyel](https://discuss.python.org/u/Saphyel)\ **Post date:** [March 15, 2023, 8:55pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/151 "2023-03-15T20:55:11Z")
I’m not really happy with the wording in “Opting out of virtual environments”. it MUST provide an opt-out. What if if you are installing an OS package globally (let’s say something like youtube-dl, Graphor, etc…) ? What if I don’t want to use VE at all? ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [March 15, 2023, 9:05pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/152 "2023-03-15T21:05:40Z")
> [@BrenBarn](#): > > > [@PythonCHB](#): > > > > I wonder about `.venv` for newbies. > > Yes, and for Windows users. The “dotfile” convention is very unixy-centric. Since VS Code adopted it we have not run into any confusion or concerns from beginners, just advanced users being concerned for beginners (and that’s a serious comment; we have gotten way more complaints from advanced users wanting to search their virtual environment for some code and having some tool ignore `.` stuff by default). I suspect most beginners don’t even think about it being some convention or question it; to them I suspect it’s “just how things are,” and move on; they are just following the instructions. I also think you’re assuming beginners are doing raw terminal work and not some tool which will show things differently than e.g. the Finder in macOS, and once again, with no instructions on e.g. activation next or something else they are going to just blindly type in the terminal. Honestly, the much bigger problems for beginners are _putting_ their code in their virtual environment or committing it to version control (which is why VS Code’s **Create Environment** command drops a `.gitignore` file in the virtual environment directory). ---
**Author:** ![PythonCHB](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pythonchb/32/2551_2.png) [@PythonCHB](https://discuss.python.org/u/PythonCHB)\ **Post date:** [March 16, 2023, 5:04am UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/153 "2023-03-16T05:04:13Z")
> [@brettcannon](#): > > I also think you’re assuming beginners are doing raw terminal work and not some tool which will show things differently than e.g. the Finder in macOS, I’m not assuming that, but I’m a bit confused – the Finder in OS-X hides dotfiles by default. I think that’s a greater potential source of confusion than Windows, where, IUUC, there’s nothing special about dotfiles. This is no different than, say a ` __init__.py` file being something special. Are you suggesting that folks don’t use Finder for looking at their projects? ---
**Author:** ![ntessore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ntessore/32/10786_2.png) [@ntessore](https://discuss.python.org/u/ntessore)\ **Post date:** [March 16, 2023, 9:23am UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/154 "2023-03-16T09:23:19Z")
It’s a bit of a tangent, but I often wish that `pip install` had a `--local` switch akin to `--user` that installed packages into ` __pypackages__ `, say, in the local folder. This local installation would be lightweight and completely transparent, without explicit activation, and would work on top of venv, conda, etc. As such, it would be part of the import system in Python rather than any specific package manager. In the spirit of this PEP, if global installation is impossible, e.g. because of `EXTERNALLY-MANAGED`, then `pip` could say: “You can install packages locally into the current folder using `pip install --local`.” This would not elevate venv or any other tool above any others. Ideally, the local install would keep a list of installed packages that can be committed, as well as the actual binaries separated by Python ABI, so that you can just reinstall the local packages with some command should you switch machines or Python version. ---
**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\ **Post date:** [March 16, 2023, 12:06pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/155 "2023-03-16T12:06:28Z")
NB, this seems a lot more relevant to [the PEP 582 thread](https://discuss.python.org/t/pep-582-python-local-packages-directory/963) instead ---
**Author:** ![fungi](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/fungi/32/5963_2.png) [@fungi](https://discuss.python.org/u/fungi)\ **Post date:** [March 16, 2023, 12:18pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/156 "2023-03-16T12:18:08Z")
Is `pip install -t __pypackages__ foo` not sufficient? That can be aliased to something else rather trivially if it’s too much to type. Remember that pip can install packages anywhere now, and into any existing Python environment too, like: ```auto python3 -m venv __pypackages__ pip --python __pypackages__ /bin/python3 install foo ``` No activation is required to do that. ---
**Author:** ![ntessore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ntessore/32/10786_2.png) [@ntessore](https://discuss.python.org/u/ntessore)\ **Post date:** [March 16, 2023, 12:29pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/157 "2023-03-16T12:29:20Z")
The installation isn’t so much the problem as that i) it should be picked up automatically as the first path by importlib, and ii) it should be organised such that the list of local packages is separated from the installations of said packages, because of committing, relocating, etc. But maybe both are easily doable nowadays? ---
**Author:** ![fungi](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/fungi/32/5963_2.png) [@fungi](https://discuss.python.org/u/fungi)\ **Post date:** [March 16, 2023, 1:00pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/158 "2023-03-16T13:00:07Z")
Well, now you’re asking for default behavior changes to the Python interpreter, not pip. Different stakeholders with a different process for requesting and agreeing on behavior changes. That’s where the aforementioned PEP discussions come into play. ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [March 16, 2023, 9:54pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/159 "2023-03-16T21:54:04Z")
> [@PythonCHB](#): > > Are you suggesting that folks don’t use Finder for looking at their projects? Not “don’t”, but not “always” either. As I said, I have never had someone talk to me about some struggles a beginner had from a virtual environment being named `.venv` and it being hidden by default on macOS (or any other OS). ---
**Author:** ![PythonCHB](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pythonchb/32/2551_2.png) [@PythonCHB](https://discuss.python.org/u/PythonCHB)\ **Post date:** [March 17, 2023, 5:18am UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/160 "2023-03-17T05:18:52Z")
> [@brettcannon](#): > > I have never had someone talk to me about some struggles a beginner had from a virtual environment being named `.venv` and it being hidden by default Good to hear – we need to learn from actual experience. For my part, when I’ve taught (or tried to) virtual environments, beginners have found the whole thing confusion – so can’t say a possibly hidden directory name has or hasn’t been a contributor to that confusion. But why? dotifles are a convention in the \*nix world, but only that world. If it’s a well accepted convention already then sure, but from this thread I’m not sure that’s the case. ---
**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\ **Post date:** [March 17, 2023, 1:07pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/161 "2023-03-17T13:07:27Z")
> [@petersuter](#): > > Could it instead default to behave like `python -m venv .venv`? (If that is / will be the recommendation.) > > That would look less confusing and overwhelming to beginners, is easier to type, reduces the amount of details to lookup or remember, feels more “official”, and has no obvious downsides or impact on more advanced use cases or users that prefer a different name. It would have to print an explicit message telling the user that `.venv` is chosen as the virtual environment directory, then. Nothing worse than having a command silently succeed without knowing what it did. ---
**Author:** ![petersuter](https://avatars.discourse-cdn.com/v4/letter/p/13edae/32.png) [@petersuter](https://discuss.python.org/u/petersuter)\ **Post date:** [March 17, 2023, 4:08pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/162 "2023-03-17T16:08:14Z")
(I agree. Unix folks might prefer [The Rule of Silence](http://www.linfo.org/rule_of_silence.html).) ---
**Author:** ![fungi](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/fungi/32/5963_2.png) [@fungi](https://discuss.python.org/u/fungi)\ **Post date:** [March 17, 2023, 5:01pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/163 "2023-03-17T17:01:17Z")
Yes, many users coming from other operating system paradigms are often confused when they run a command and get no output, thinking it means something is wrong. For those of us who have used Unix and its derivatives and clones for decades, we assume no output means success and if a trivial command displays something then it’s probably alerting the user to an error. This has (unfortunately in my opinion) slowly eroded as developers who started in other ecosystems begin to port software and print lots of unnecessary information, forcing the user to add a --quiet option to commands or, worse, redirect standard output and maybe even standard error to a null sink in order to just make them shut up, or pipe them through complex patter-matching filters in order to get rid of all the noise without missing actual errors that get mixed in. For the same reasons, I much prefer dotfiles and dotdirs for storing “unimportant” data, leaving only important-to-me directories in my listings (where my documents reside, directories in my default executable path, and so on). If I _want_ to list the unimportant ones too, there’s a non-default command line option I can supply to see them. I get the impression I’m not alone in that sentiment, though it seems increasingly likely we may be part of an aging population that values silence, focus, minimalism, and lack of distraction… and that people are more recently being trained to prefer noise and constant validation. Overarching software design paradigms certainly seem to be changing in ways that make things less usable for me, but that may very well mean I’m the problem. 😉 ---
**Author:** ![Kwpolska](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/kwpolska/32/10542_2.png) [@Kwpolska](https://discuss.python.org/u/Kwpolska)\ **Post date:** [March 18, 2023, 6:35pm UTC](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/164 "2023-03-18T18:35:11Z")
Unix tools have their idiosyncracies, but Python is not part of Unix/POSIX proper, and the world has changed since POSIX was introduced. I think that tools that are meant for mass adoption should be more verbose, friendly, and informative, to help users understand what’s happening, Unix tradition be damned. `pip install requests` produces 17 lines of output in a clean environment. `git init` produces one line. I think that `python -m venv` should produce at least one confirmation line too. Possibly more, so that the users know that the tool is busy creating the venv and installing things into it (as it takes a few seconds, especially on slower hardware). > [@fungi](#): > > For the same reasons, I much prefer dotfiles and dotdirs for storing > “unimportant” data, leaving only important-to-me directories in my > listings (where my documents reside, directories in my default > executable path, and so on). Dotfiles were a bit of a hack in early Unix. They are more of an official thing now, but if you are making tools, please don’t clutter my home directory with your stuff (dotfiles or not), but instead put it in the appropriate configuration directory (`~/.config` on Linux/XDG, `~/Library` on macOS, and `~\AppData` on Windows). [Previous page](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846.md?page=7) [Next page](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846.md?page=9)