Virtual Environments: python -m venv VS echo layout python3

Question

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 and then direnv allow.

What are the differences or advantages to using python -m venv <virtualenv name> versus echo layout?

Answer 1

Those two commands do entirely different things.

venv

The 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.

direnv and .envrc

First, about that echo command...

In both MS-DOS and Unix / Linux (and presumably recent versions of Macintosh), echo layout python3 just emits a string "layout python3".

The > 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:

layout python3

The .envrc file, and direnv allow

.envrc is a config file used by the direnv application. Whenever you cd into a directory containing a .envrc file, 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 allowed.

Finally, back to direnv

I don't use direnv, but 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.

(Dis-)Advantages and Opinions

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.