This pep already partially does that.

> The error message SHOULD inform the user that a virtual environment is required, SHOULD provide shell-specific instructions on how to create and activate a virtual environment named .venv, and SHOULD provide a link to a documentation page that explains how to create and activate a virtual environment.

Why do you say this is one of the coolest part?

Because the best part about unix/linux is that everything is a file (or more broadly, everything are files and folders) and this is congruent with that.

The more I program, the more I appreciate:

- 1. tools that are extremely small and functional and can be composed together (re: unix pipes, cat foo | grep bar)

- 2. things that are just files and folders on disk, so that they can get introspected, moved to different disks, symlinked, put on FUSE filesystems, etc. The common interface of file or folder is very flexible.

Nothing about that proposal changes how venvs work. It just changes what the global python command does. Anything you do explicitly with a venv today, you could still do under that proposal.

I'd call this a minor convenience at best. Symlinks would still make it possible, of course.

I know it's not the end of the world, but I prefer to keep my dependencies outside of the project root in deployed scenarios. Ex, /srv/venv and /srv/app