I'm fairly new to python, but have built a few small projects. I have been taught, and have always used, the following commands to start a virtual environment:
echo layout python3 > .envrc
python -m venv <virtualenv name>
Those two commands do entirely different things.
python -m venv <env_name> command creates a virtual environment as a subdirectory full of files in your filesystem. When it's done, a new virtual environment is sitting there ready for you to activate and use, but this command doesn't actually activate it yet.
Activating the virtual environment so you can use it is a separate step. The command to do this depends on which operating system and which shell you're using (see the "Command to activate virtual environment" table in the docs linked above).
The activation command alters only your current command-line shell session. This is why you have to re-activate the virtual environment in every shell session you start. This kind of annoyance is also what
direnv exists to solve.
In both MS-DOS and Unix / Linux (and presumably recent versions of Macintosh),
echo layout python3 just emits a string
> redirects the
echo command's output to a file, in this case
.envrc. The redirection creates the file if it doesn't already exist, and then replaces its contents (if any) with that string. The end result is a file in your current working directory containing just:
.envrc is a config file used by the
direnv application. Whenever you
cd into a directory containing a
direnv reads it and executes the
direnv instructions found inside.
direnv allow is a security feature. Since malicious
.envrc files could be hidden almost anywhere (especially in world-writable directories like
/var/tmp/), you could
cd into a seemingly innocent directory and get a nasty surprise from someone else's
.envrc land mine. The
allow command specifically white-lists a directory's
.envrc file, and apparently un-lists it if it discovers the
.envrc file has changed since it was
I don't use
layout <language> is a
direnv command to adjust your environment for developing in language, in this case activating a Python 3 virtual environment. The docs hint that it's more "helpful" than just that, but they don't go into any detail. (Also, you could have written your own
direnv function called
python3 that does something completely different.)
The goal of all that is to automatically enable your Python virtual environment as soon as you
cd into its directory. This eliminates one kind of human error, namely forgetting to enable the virtual environment. For details, see Richard North's "Practical
direnv", especially the "Automatic Python
virtualenv switching section.
If that's the kind of mistake you've made frequently, and you trust that the
direnv command will never fall prey to a malicious
.envrc file (or otherwise "helpfully" mess up something you're working on), then it might be worth it to you.
The biggest down-side I see to
direnv (aside from the security implications) is that it trains you to forget about a vital step in using Python virtual environments... namely, actually using the virtual environment. This goes double for any other "help" it silently provides without telling you. (The fact that I keep putting "help" in quotes should suggest what I think of utilities like this.)
If you ever find yourself working somewhere
direnv isn't installed, the odds are good that you'll forget to activate your virtual environments, or forget whatever else
direnv has been doing for you. And the odds are even better that you'll have forgotten how to do it.