3 ms·
Apparently, you're new to back-end programming? We have similar "locally installed package" abstractions in every major language there: C++ -> vcpkg Ruby -> b
by fxtentacle 4y ago
Apparently, you're new to back-end programming? We have similar "locally installed package" abstractions in every major language there:
C++ -> vcpkg
Ruby -> bundler
Node -> npm vendor
Go -> Go Modules
Java -> Maven
If you disagree, please explain how Ruby's bundler caching dependencies in a vendor subfolder differs from Python's venv caching dependencies in a subfolder and why one of them is a dumpster fire that and the other one doesn't exist.
- thiht 4y ago> Node -> npm vendor > Go -> Go Modules These are transparent though. You don't need to "activate" your venv when you enter your project's directory. You can't misuse it. You can't fuck up everything because you switched project and forgot to change the venv. For Go you don't even need gvm or anything like that because of the compatibility promise. Just use the latest and be done with it.
- PaulHoule 4y agoWhen I have been doing analysis work I typically create a suite of command line programs to do that work with. Systems like nom and maven lock me in a prison because they are dependent on the directory I am in…. They take away the ability to cd to an arbitrary directory and run my command line programs. I can’t see why people want to take the X out of Unix like that, maybe they remember using CP/M and never really figured out cd and mkdir and they want to bring us all to their level. With a .venv however the program suite I am running and directory I am are decoupled and I can breathe free.
- potta_coffee 4y agoGo modules and NPM are easy to use. Virtualenvs are a pain in the ass to configure. That's the difference really. If I could just go to my Python project directory and "virtualenv init" then this wouldn't be a conversation topic.