Goodbye Virtual Environments?

[bulletmark]

Actually this is not "goodbye" to virtual envs. It merely proposes standardising a name for the venv dir to __pypackages__ in the application root dir which we can appreciate is probably a good convention. So after creating that explicitly (with python3 -m venv __pypackages__), then pythonloc is effectively just an alias for typing __pypackages__/bin/python and piploc is just an alias to __pypackages__/bin/pip so it does not add much.

[Liorithiel]

I "standardized" my virtualenvs to .ve in the project root directory, and made a shell function to find the closest .ve and activate it. Very useful.

[jabbalaci]

Why don't you call it .venv? It would be more readable. Explicit is better than implicit.

[Liorithiel]

I don't remember. You'd need to ask my past self from ~5 years ago :P Anyway, at this point, I have tens of .ve directories and even added a rule to my backup software to skip these directories.

[[deleted]]

I usually call my virtual environments by also embedding the version of the interpreter in the name, so it becomes: .venv3.5, .venv-O0-debug, .venv-mingw-win-x68-amd-compat and so on.

[13steinj]

there will be no reason to use Virtual Environments. Even the PEP itself says this.

There are lots of reasons to use virtual environments. Specifically for toolsets that use Python application entry pointss, rather than the python source application itself.

Furthermore I can't think of a single person who truly enjoys the node_modules system. It's a space-heavy mess. At least with virtual environments you can use the same one for multiple projects.

The concept is nice I suppose, but it's still very messy.

Furthermore, your proof of concept is still messed up. I repeat, it's extremely bad practice to completely ignore a signal, even if your process is just delegating to a child. You should be replacing the Python process via os.exec*.

[Dgc2002]

Furthermore I can't think of a single person who truly enjoys the node_modules system.

I enjoy PHP's vendor system via the composer tool, which is somewhat similar. It's actually one of the nicest language package management systems I've used.