This helped me understand what it boiled down to, and presented a simple solution back in the day, when fish shell wasn’t suportes by venv. https://gist.github.com/AlexanderAA/4970724
To me, the problem is that virtualenv was a neat hack to simulate project local dependencies, while in fact only supporting global dependencies. It’s a very clever hack! But it is long since past time for retirement. Node, Go, and Rust don’t require any shell modifications to work. (Although Go used to require the GOPATH env var, which developers hated, so they stopped relying on it.)
Node, Go, and Rust don’t require any shell modifications to work.
Neither does Python. The “shell modifications” are simply a convenience to ensure the venv’s python executable is found first on your path – if you explicitly invoke that executable by typing the full path to it, it doesn’t require any environment modifications.
Also, of the three you list only Node uses the same runtime/“dynamic linking” style as Python – Rust and Go both use static linking and so only need to have a project-specific build directory. If Go and Rust had to deal with dynamic linking, they’d end up with either a single site-wide shared location (similar to Python, and C, and lots of other languages) or have to cook up some form of per-project runtime isolation of dependencies.
Node suffers from the same problem that prevents python from relying on global dependencies. References to binaries installed at the system level.
It just leaves the problem unsolved and pretends it doesn’t exist. GitHub is littered with c libraries error messages trigger e from node apps.
Go and rejected the problem by starting from scratch and writing all their dependencies.
I’m not sure what you mean by “binaries”: DLLs or executables. Node keeps executables in node_modules/.bin. That works pretty well. Like Python, for C-modules, the best way to use a module that requires a DLL in Node is to have an external package manager that has the job of installing DLLs. Trying to get it to install automatically is basically a recipe for pain. In practice, Node seems to have fewer libraries that require C, but I think it’s mostly just a matter of Pandas and Numpy not existing in Node.
Reminds me of https://imgs.xkcd.com/comics/python_environment.png
This helped me understand what it boiled down to, and presented a simple solution back in the day, when fish shell wasn’t suportes by venv. https://gist.github.com/AlexanderAA/4970724
To me, the problem is that virtualenv was a neat hack to simulate project local dependencies, while in fact only supporting global dependencies. It’s a very clever hack! But it is long since past time for retirement. Node, Go, and Rust don’t require any shell modifications to work. (Although Go used to require the GOPATH env var, which developers hated, so they stopped relying on it.)
Neither does Python. The “shell modifications” are simply a convenience to ensure the venv’s
pythonexecutable is found first on your path – if you explicitly invoke that executable by typing the full path to it, it doesn’t require any environment modifications.Also, of the three you list only Node uses the same runtime/“dynamic linking” style as Python – Rust and Go both use static linking and so only need to have a project-specific build directory. If Go and Rust had to deal with dynamic linking, they’d end up with either a single site-wide shared location (similar to Python, and C, and lots of other languages) or have to cook up some form of per-project runtime isolation of dependencies.
And a Node-style approach of a specific magically-named “local package dir” is under discussion for Python.
It’s been about 5 years since it was proposed. Is there any movement?
Node suffers from the same problem that prevents python from relying on global dependencies. References to binaries installed at the system level. It just leaves the problem unsolved and pretends it doesn’t exist. GitHub is littered with c libraries error messages trigger e from node apps.
Go and rejected the problem by starting from scratch and writing all their dependencies.
I’m not sure what you mean by “binaries”: DLLs or executables. Node keeps executables in node_modules/.bin. That works pretty well. Like Python, for C-modules, the best way to use a module that requires a DLL in Node is to have an external package manager that has the job of installing DLLs. Trying to get it to install automatically is basically a recipe for pain. In practice, Node seems to have fewer libraries that require C, but I think it’s mostly just a matter of Pandas and Numpy not existing in Node.