3 ms·

I have no idea who this appeals to, or why. If I want something, I want it to be installed and available, not mysteriously cached. If I want multiple versions o

I have no idea who this appeals to, or why. If I want something, I want it to be installed and available, not mysteriously cached. If I want multiple versions of something, there are tools like asdf and rtx. This feels like a solution for a problem that doesn’t exist.

robador 3y ago
I can see its appeal. As a former developer turned manager, I often want to solve certain problems quick, or test things. I very much don't want to install these kinds of experiments permanently as I don't have the time to maintain them. Now it often happens that I do an upgrade of something I haven't used a long time and it breaks, which wastes my time debugging. For me something that just works the couple of times I want to use it is indeed appealing.
- sgarland 3y ago
  Tbf I’m an SRE/DBRE who codes in Python, but if I need to test something, I spin up a venv, install what I need, and then am done. I also made a shell function to make temporary venvs that also launch a Jupyter Notebook with whatever packages you want, and deletes itself when done. It works well for me. To each their own. If your workflow works for you, have at it.
  - avisser 3y ago
    GP wasn't explicit, but I think his assumption was that "experiments" are things outside of your wheelhouse - e.g. you want to try out a some node code, or compile a golang app. You've already budgeted to have python on your machine and up-to-date.
    - sgarland 3y ago
      I keep a Go and Rust compiler installed for when I need to use them. I’d rather not wait for it to download and install every time I want to do so.
amadeuspagel 3y ago
Did you install hackernews before posting here?
koromak 3y ago
And yet npx is used constantly in the dev world. Theres a use case.
hn92726819 3y ago
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

robador 3y ago

I can see its appeal. As a former developer turned manager, I often want to solve certain problems quick, or test things. I very much don't want to install these kinds of experiments permanently as I don't have the time to maintain them. Now it often happens that I do an upgrade of something I haven't used a long time and it breaks, which wastes my time debugging. For me something that just works the couple of times I want to use it is indeed appealing.

sgarland 3y ago
Tbf I’m an SRE/DBRE who codes in Python, but if I need to test something, I spin up a venv, install what I need, and then am done. I also made a shell function to make temporary venvs that also launch a Jupyter Notebook with whatever packages you want, and deletes itself when done. It works well for me. To each their own. If your workflow works for you, have at it.
- avisser 3y ago
  GP wasn't explicit, but I think his assumption was that "experiments" are things outside of your wheelhouse - e.g. you want to try out a some node code, or compile a golang app. You've already budgeted to have python on your machine and up-to-date.
  - sgarland 3y ago
    I keep a Go and Rust compiler installed for when I need to use them. I’d rather not wait for it to download and install every time I want to do so.

amadeuspagel 3y ago

Did you install hackernews before posting here?

koromak 3y ago

And yet npx is used constantly in the dev world. Theres a use case.

hn92726819 3y ago

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