Live data from Hacker News

Pkgx – “Run anything” from the creator of brew

pkgx.sh

51–60 of 71 posts

Re: Pkgx – “Run anything” from the creator of brew

#51

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.

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

Re: Pkgx – “Run anything” from the creator of brew

#52
post #49
post #42

Earlier quoted context omitted.

Most language package managers have some notion of dependency resolution, since various deps declare bounds for their dependencies instead of pinned versions (since otherwise frameworks would be impossible to upgrade). Nix the language doesn't have such a thing (would be a bit of a category error), and nixpkgs the ecosystem is so far away from that kind of thing... Language ecosystems around sharing source code canno…

Yet we still have lock files. The version constraints can just be another piece of metadata that a given derivation carries with itself. You have to distinguish between declaring a dependency and using one in the compilation of a thing.

The point is that from a UX perspective, people want to be able to specify loose dependencies, and then for a constraint solver to then provide an overall set of dependencies where all of these holds.

You're saying "just use nix". Nix does not provide this. This is a fundamental feature of programming language package managers. I would love for Nix to have an interesting answer to this problem, but I think that if nixpkgs continues to exist in its current form (following more of an apt model), it will be hard for the Nix community to come up with an answer that fits well. Nixpkgs is mostly about distributing compiled assets, while programming language package managers are mostly about distributing source code. The important parts are different!

Re: Pkgx – “Run anything” from the creator of brew

#53
post #48
post #46

Earlier quoted context omitted.

"written in typescript" does not mean it's slow. V8 and JavaScriptCore are insanely fast, and typescript is a proven language.

JavaScript (typescript) is interpreted, hence will be slower than a compiled language

fast != fastest

Re: Pkgx – “Run anything” from the creator of brew

#54
post #29
post #21

Earlier quoted context omitted.

Nix Darwin supports brew, so this isn't really a reasonable argument. > So, switch to using both? This is an option, yes. Plus, it has the added benefit of you not needing to manage `brew doctor`, `brew cleanup`, etc. yourself. So you're not stuck with weird packages you installed once , never needed again, and forgot to clean up. It's strange that people are so against declarative systems, or even file-based OS conf…

> It's strange that people are so against declarative systems, or even file-based OS configuration. When I get my new Macbook I was up-and-running within a few minutes. I can't imagine maintaining a list of brews I need to re-install just to set up everything + my configs + everything else. I haven’t had time to try Nix yet, but HomeBrew does have a declarative-ish workflow that I’ve been using for years: Brew Bundle…

This is actually the mechanism behind Nix-Darwin's Homebrew support.

In Nix terms, it uses the module system to generate a Brewfile, and then it invokes the brew CLI against that file in the activation script.

Nix or no Nix, it's definitely a better way to use Homebrew than ad-hoc, imo!

Re: Pkgx – “Run anything” from the creator of brew

#55
post #12
post #5

I know I'm a Nix elitist but I really don't understand why people don't just use Nix for all their package management.

Because I don't want to learn another complex DSL just to install some packages. Whether Nix is the promised land or not, Brew works just fine 99% of the time and I have stuff to do.

> Because I don't want to learn another complex DSL just to install some packages. Whether Nix is the promised land or not, Brew works just fine 99% of the time and I have stuff to do.

It surely is complex, but I think you're intrinsically devaluing the importance of dependency management. Your important 'stuff to do' is built on top of a lot of software, getting that supply chain right (and reproducible) is at least as important.

Re: Pkgx – “Run anything” from the creator of brew

#56
post #10
post #5

I know I'm a Nix elitist but I really don't understand why people don't just use Nix for all their package management.

Or AppFS (which I wrote), which gives you all the same benefits of Nix but with less work, though currently has way less packages.

I'll have to check it out!

Re: Pkgx – “Run anything” from the creator of brew

#57
post #56
post #10

Earlier quoted context omitted.

Or AppFS (which I wrote), which gives you all the same benefits of Nix but with less work, though currently has way less packages.

I'll have to check it out!

Let me know if you have any questions (email in profile) ! Also check out CERN VM-FS [0], which is a similar idea, but AppFS has a simpler protocol and the implementation supports writing (writes by a user go to their home directory, so each user can have a different view of the packages).

[0] https://cernvm.cern.ch/fs/

Re: Pkgx – “Run anything” from the creator of brew

#58

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.

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…

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.

Re: Pkgx – “Run anything” from the creator of brew

#59
post #45

Earlier quoted context omitted.

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.

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.

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.

Re: Pkgx – “Run anything” from the creator of brew

#60

Earlier quoted context omitted.

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…

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…

> 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

Post reply on HN