I’ll echo the “what’s the difference between this and Nix” sentiment, but what’s really interesting to me is if it handles the hard cases. All I see is “easy” examples with Rust and Go.
Let’s be mean and go for the ugliest one - python 3.8.6 (or whatever specific version) along with numpy, matplotlib along with pytorch and the CUDA system libraries (of course, all of them pinned to specific versions).
There is no claim that this is competing with Nix. The opposite in fact; we suggest using Nix if you need a full package manager.
Though since you bring it up, Python is supported, and both matplotlib and numpy work fine. Hermit doesn’t install libraries, so naturally the CUDA libraries are not supported.
Thanks for your informative response! I was trying to figure out where the tool fit in (my mind’s view) of the whole distro packaging/docker/nix/language packages mess.
To be fair, Nix/NixOS doesn’t handle that python/torch/CUDA dumpster fire of a situation too well either. It makes it possible, but you have to work for it…
It was inspired by the issue at Cash of maintaining consistent tooling across all developer machines, as well as CI. Developers would frequently need version X of a toolchain but have version Y from Homebrew and Z on the Linux CI machines. Hermit solves that by versioning all tools in the Git repo in which they are used. It’s like magic!
Cool project! You mention developer machines and CI, so you are not yet(?) using it for production environments? Are there plans to? If not, how do you ensure your dev & ci envs match prod? :)
That’s a great question. We use Go and the JVM on Docker. For the former this is not relevant, and for the latter slight divergence in JVM versions is not an issue.
That said, Hermit offers introspection, so you could easily tie the Docker version of a runtime to the Hermit version of that runtime:
🐚 ~/Projects/project $ hermit info go --json | jq -r '.[].Reference.Version'
1.17.2
You could also use the identical upstream package that Hermit itself uses, in a similar manner:
🐚 ~/Projects/project $ hermit info go --json | jq -r '.[].Source'
https://golang.org/dl/go1.17.2.darwin-arm64.tar.gz
That looks really nice! If I had not been at the point where I almost gave up on packaging before I invested months(!) to “properly” learn Nix, NixOS and the surrounding ecosystems - I would totally try Hermes. :)
Yeah I love Nix, but the learning curve is significant, and requiring 100’s of engineers to learn Nix just to install some packages was not practical IMO.
We’d love to support other operating systems, Windows being the most obvious choice, but BSDs as well. We’d also like to support more shells, such as Fish.
I’ve used direnv, and Nix, but not Nix flake. Hermit is more akin to asdf.
It differs from Nix primarily in that there’s no installation required at all when using a Hermit-enabled repo. You just clone it down and Hermit will auto-install itself and any packages in the repo as they’re used.
The FAQ has a section comparing it to different package managers including Nix.
Hermit seems to carve out a smaller scope. In particular, it doesn’t model the process of building tools–just downloading them. And it doesn’t try to manage low level dependencies like libc nor higher level stuff like recreating pypi, npm, and crates.io
And it doesn’t try to provide security beyond https. No hashes, signatures, etc.
Actually it works at a per-project level! Each project can have a completely separately versioned set of tools. But yes, the problem you describe is exactly the problem Hermit is designed to fix.
That said, we don’t (yet) have any C/C++ toolchains packaged 🙁, and we explicitly don’t support server software like Postgres, because Docker already solves that problem in a better way. We would love to make C/C++ toolchains available though.
I’ll echo the “what’s the difference between this and Nix” sentiment, but what’s really interesting to me is if it handles the hard cases. All I see is “easy” examples with Rust and Go.
Let’s be mean and go for the ugliest one - python 3.8.6 (or whatever specific version) along with numpy, matplotlib along with pytorch and the CUDA system libraries (of course, all of them pinned to specific versions).
There is no claim that this is competing with Nix. The opposite in fact; we suggest using Nix if you need a full package manager.
Though since you bring it up, Python is supported, and both matplotlib and numpy work fine. Hermit doesn’t install libraries, so naturally the CUDA libraries are not supported.
Thanks for your informative response! I was trying to figure out where the tool fit in (my mind’s view) of the whole distro packaging/docker/nix/language packages mess.
To be fair, Nix/NixOS doesn’t handle that python/torch/CUDA dumpster fire of a situation too well either. It makes it possible, but you have to work for it…
(… I am astroturfing a bit here)
Hey @alec, what inspired Hermit and its design?
👋😀 (@quad works at Cash also)
It was inspired by the issue at Cash of maintaining consistent tooling across all developer machines, as well as CI. Developers would frequently need version X of a toolchain but have version Y from Homebrew and Z on the Linux CI machines. Hermit solves that by versioning all tools in the Git repo in which they are used. It’s like magic!
Cool project! You mention developer machines and CI, so you are not yet(?) using it for production environments? Are there plans to? If not, how do you ensure your dev & ci envs match prod? :)
Thanks :)
That’s a great question. We use Go and the JVM on Docker. For the former this is not relevant, and for the latter slight divergence in JVM versions is not an issue.
That said, Hermit offers introspection, so you could easily tie the Docker version of a runtime to the Hermit version of that runtime:
You could also use the identical upstream package that Hermit itself uses, in a similar manner:
That looks really nice! If I had not been at the point where I almost gave up on packaging before I invested months(!) to “properly” learn Nix, NixOS and the surrounding ecosystems - I would totally try Hermes. :)
Yeah I love Nix, but the learning curve is significant, and requiring 100’s of engineers to learn Nix just to install some packages was not practical IMO.
Regarding your first point though (which is a great one), I created a ticket to track creating production bundles: https://github.com/cashapp/hermit/issues/162
This looks interesting. Really like the choice of HCL and the package specification looks nice.
For this claim I think supporting more operating systems might make sense.
Looking at things that might not be too hard though.
We’d love to support other operating systems, Windows being the most obvious choice, but BSDs as well. We’d also like to support more shells, such as Fish.
It’s just a matter of a lack of humans!
Which ones?
Can any users familiar with both talk to a comparison of a Nix flake + direnv? Just trying to build my own mental model of Hermit
I’ve used direnv, and Nix, but not Nix flake. Hermit is more akin to asdf.
It differs from Nix primarily in that there’s no installation required at all when using a Hermit-enabled repo. You just clone it down and Hermit will auto-install itself and any packages in the repo as they’re used.
The FAQ has a section comparing it to different package managers including Nix.
Hermit seems to carve out a smaller scope. In particular, it doesn’t model the process of building tools–just downloading them. And it doesn’t try to manage low level dependencies like libc nor higher level stuff like recreating pypi, npm, and crates.io
And it doesn’t try to provide security beyond https. No hashes, signatures, etc.
This is mostly accurate, except there are opt-in SHA-256 hashes.
A question (apologies in advance, if this has been covered in docs, I might have missed it).
Does it work at ‘user account’ level or at a machine level?
Sometimes, for maintenance on the old base, older tools are needed (for C++ for example older compiler), old postgres (db + cli).
Can two user accounts on the same VM coexist , but use different set of tools (eg for C++/Postgres/boost/cmake) for each of the accounts ?
Actually it works at a per-project level! Each project can have a completely separately versioned set of tools. But yes, the problem you describe is exactly the problem Hermit is designed to fix.
That said, we don’t (yet) have any C/C++ toolchains packaged 🙁, and we explicitly don’t support server software like Postgres, because Docker already solves that problem in a better way. We would love to make C/C++ toolchains available though.