3 ms·

Really? Are you a developer? Do you use any language that tries not to pollute the system or even user dirs (rust, go, npm/yarn, maven, virtualenv)? It's so muc

Really? Are you a developer? Do you use any language that tries not to pollute the system or even user dirs (rust, go, npm/yarn, maven, virtualenv)? It's so much nicer to separate versions of things from system-installed versions of things. If you are one, could you imagine how annoying it would be if these languages all only allowed one installed version at a time on your system? How could you ever manage to work on two medoum-large projects at once? One requires left-pad 0.1, the other requires left-pad 0.1.1 etc. This is solved for many languages: have one directory per project (node_modules, target) and optionally have a user cache so you don't have to redownload stuff. Or, have one usercache, but still separate by versions. I think people know how painful c and c++ versions are and don't want to do that again. Even with c/c++: cmake, automake, and bazel are there to wrangle package versions. Though, I do agree things like Firefox or Thunderbird don't need to be hidden in a mysterious cache location

sgarland 3y ago
Not a dev, SRE/DBRE, but as I mention in a child comment, I make use of venvs for Python all the time, usually via Poetry. That’s the part I don’t get; this reads like it’s replacing brew. Libraries are entirely different from applications. I can easily see wanting a library temporarily to satisfy a version constraint, but something I’m going to use directly? Why? If it’s for the interpreter (Python for example), and someone has pinned it to a specific - not floating up - requirement, that’s a problem with the author IMO. I shouldn’t need to install 3.7.3 when semver (if taken seriously, which Python does) states that >= 3.7 suffices. I have no comment on Node because the entire ecosystem is a hellscape.
- hn92726819 3y ago
  > use of venvs for Python all the time Ah I think that's why then. Venvs are IMO the best of every example I've given. When you make one, Python is embedded in the venv. So your system python doesnt really matter. As long as it creates a valid python venv and embeds a valid version of Python, you're fine after sourcing the venv. I believe every other one of those versions libraries, but not the go/cargo/rustc/node programs themselves. There are solutions for each language independently, just as there is for python, but we don't have it as easy as you do with venvs which take care of both at the sane time! But I do agree. If you're using something all the time, just brew install it, which is also what you've done with python I'm assuming. This just brings the power of venvs to every language. Also I'm not surprised that the owner of brew chose to override such a monumentally important command like `env`... Smh

sgarland 3y ago

Not a dev, SRE/DBRE, but as I mention in a child comment, I make use of venvs for Python all the time, usually via Poetry. That’s the part I don’t get; this reads like it’s replacing brew. Libraries are entirely different from applications. I can easily see wanting a library temporarily to satisfy a version constraint, but something I’m going to use directly? Why? If it’s for the interpreter (Python for example), and someone has pinned it to a specific - not floating up - requirement, that’s a problem with the author IMO. I shouldn’t need to install 3.7.3 when semver (if taken seriously, which Python does) states that >= 3.7 suffices. I have no comment on Node because the entire ecosystem is a hellscape.

hn92726819 3y ago
> use of venvs for Python all the time Ah I think that's why then. Venvs are IMO the best of every example I've given. When you make one, Python is embedded in the venv. So your system python doesnt really matter. As long as it creates a valid python venv and embeds a valid version of Python, you're fine after sourcing the venv. I believe every other one of those versions libraries, but not the go/cargo/rustc/node programs themselves. There are solutions for each language independently, just as there is for python, but we don't have it as easy as you do with venvs which take care of both at the sane time! But I do agree. If you're using something all the time, just brew install it, which is also what you've done with python I'm assuming. This just brings the power of venvs to every language. Also I'm not surprised that the owner of brew chose to override such a monumentally important command like `env`... Smh