i..i've never seen a homebrew for linux user in the wild

I use Linuxbrew extensively across multiple WSL distros every day. As the “weird Windows person” on a team full of Mac users the experience is pretty uniform—the same brew commands for standing up a macOS dev environment mostly “just work” on WSL/Linux.

I've started using it as a goto for vendor tooling (go, node, etc), great experience so far and will likely continue.

I've been using Linuxbrew for few months last year, it was always hit-or-miss whether some tool will work or if it will be macOS only recipe.

Then I started using aarch64 CPUs, and Linuxbrew still doesn't work on those. Bummer.

So while I'd love to see a package manager that spans all Linux distros, Homebrew is not it, at least for now. Nix may be it, but it has its own interesting issues at times.

I recently used distrobox to run Arch Linux container on Fedora host and it was a good experience. I did not try exposing the CLIs from there to the host OS but it sounds possible https://github.com/89luca89/distrobox/blob/main/docs/usage/d... . I don't want to daily-drive Arch again, but it's a great project to install fresh versions of various CLI tools from.

I use linuxbrew at work which uses relatively old SLES 12 machines with some odd configs. I find the nix portable solutions don't work because the kernel is too old to support the needed sandbox features. I do have a coworker who got NIX working in his account, but it was non-trivial, and still had issues.

Still, several homebrew packages need some tweaking, but that is straightforward.

I think people make projects like these because by the time they have need of the tools, they've already formed strong opinions about how those tools should work. Otherwise even Homebrew wouldn't exist, because pkgsrc already did.

Opinions are great! Everybody has one! And I also feel that sticking to the tools that we know is as good as chasing the perfect "toolkit".

Complaining can be justified, and smart! But I think that those who try get extra points!

Sorry if I came across negative; it was more my intent to paint motivations as a positive thing. All these projects definitely learn from each other, and different priorities bring new approaches. I think it's how the industry moves forward, but I can see how my phrasing might be read as dismissive. Not my intent at all!

Sure thing! Didn´t get any negative vibes... I just wanted to second that we all use the tools that fit how we think and feel, and that's ok.

Wanting to solve a problem, and trying, is great, even if the problem is niche.

Hi, I am the package maintainer for https://github.com/metis-os/hysp-pkgs (The default source that's shipped with hysp)

To address your concerns:

1. Hysp is completely agnostic: Does not depend on or care about what OS, Architecture & dependencies are installed. Just parses config.toml, based on that, installs what's defined & how is it defined.

2. No Toolchains or any other kinds of dependencies are required. Each & every single binary is statically compiled. This is the core at philosophy of Hysp. A single binary that runs anywhere. No dependencies whatsoever. This saves enormous space, storage & time.

3. Self-Hostable : As installing random binaries from random sources is not advisable due to security concerns, the pkg-source can be self-hosted by anyone and hysp can be configured to use that instead of the default source.