So this tool is like "fuck", as it looks at the previous command and figures out what the user wanted to do. https://github.com/EricFreeman/fuck
Yea but ”fuck” just autocompletes your misspelling
Pkgx installs and executes what you want.
Pkgx – “Run anything” from the creator of brew
31–40 of 71 posts
Re: Pkgx – “Run anything” from the creator of brew
#32I 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.
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.
Re: Pkgx – “Run anything” from the creator of brew
#33I know I'm a Nix elitist but I really don't understand why people don't just use Nix for all their package management.
There's been some discussion around this, where tools like Nix and Bazel do a bunch of work figuring out how to get various packages working in their ecosystem, but often fail to actually get that work upstreamed in a reasonable way.
For example, if you have a JS project with a package.json, Nix offers node2nix as a way to transform that package.json into Nix-like expressions. But in an alternate universe npm and lockfiles would "work" well enough to where we wouldn't need to rely on nix for package pinning.
There's all this work put into reproducibility that thinks that the answers are around adding wrappers around the existing tooling. It's good as a last resort, but if those efforts were going more into each language's ecosystem may we would end up in a scenario where each packaging tool didn't have to come up with its own magic way of doing things.
Nix and Bazel are complex because they try to hard to work well despite the tooling, rather than getting tooling to a place where all these layers of hacks were not an issue. And so downstream of that, "simple" tools become too complex from all the incidental complexity introduced by this way of doing things.
Re: Pkgx – “Run anything” from the creator of brew
#34I literally don't understand the first example. What just happened here? Did pkgx see that I failed to run bun and then just like... installed it and ran it for me? Does that mean on my next prompt I should run `bun` or should I run `pkgx` again? $ bun command not found: bun ^^ type `pkgx` to run that $ pkgx running `bun`… Bun: a fast JavaScript runtime, package manager, bundler and test runner. # …
It might have one splendidly named thefuck under the hood: https://github.com/nvbn/thefuck
Re: Pkgx – “Run anything” from the creator of brew
#35So this tool is like "fuck", as it looks at the previous command and figures out what the user wanted to do. https://github.com/EricFreeman/fuck
Yea but ”fuck” just autocompletes your misspelling Pkgx installs and executes what you want.
Zero System Impact
We don’t install packages. We cache them.
Re: Pkgx – “Run anything” from the creator of brew
#36Earlier quoted context omitted.
You don't need to learn the DSL to use Nix as a package manager.
Do you have a link to where I can read about using Nix as purely a package manager? Or a minimal example showing how a Nix config looks if used in this manner?
Julia Evans has an article pretty much about what you’re asking for!
I think looking at nix-shell for getting some things into PATH temporarily would also be quite useful, although Julia deliberately left it out of the article. It’s just as simple as running `nix-shell -p pkg1 pkg2` if that’s all you want to do with it!
Re: Pkgx – “Run anything” from the creator of brew
#37I know I'm a Nix elitist but I really don't understand why people don't just use Nix for all their package management.
There's been some discussion around this, where tools like Nix and Bazel do a bunch of work figuring out how to get various packages working in their ecosystem, but often fail to actually get that work upstreamed in a reasonable way. For example, if you have a JS project with a package.json, Nix offers node2nix as a way to transform that package.json into Nix-like expressions. But in an alternate universe npm and loc…
Instead of relying on npm and maven and other language specific tooling, maybe we could rely on Nix to do the package management instead? NPM, Cargo, maven, whatever Python people think is good this Thursday, Go's reluctant dependency manager are all solving the same problems. And every single one of them could do a better job.
Re: Pkgx – “Run anything” from the creator of brew
#38Earlier quoted context omitted.
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.
Me, too, and also I already have a bunch of brew packages which I know are well maintained. So, switch to using both? Uninstall brew packages and install nix versions, verifying they are all maintained over there? Sorry, no.
Ah, yes, I love it when I need to wait minutes to install a package because brew needs to do some other thing.
Re: Pkgx – “Run anything” from the creator of brew
#39I 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.
Did you install hackernews before posting here?
Re: Pkgx – “Run anything” from the creator of brew
#40Edit: I was wrong the example is fine.
I find it actually useful, sometimes I may want to try something temporarily for intermediate result now and then and having it installed doesn’t yield benefits.
Good example: I generate asyncapi docs and doing an npx is fine. Alternative approach like pulling a docker image and the executing something with all volume sharing, ports what not is a but cumbersome because am too lazy to press too many keys.