I’m trying to find a thing, and I’m not turning up anything in my web searches so I figure I’d ask the cool people for help.
I’ve got several projects, tracked in Git, that rely on having a set of command line tools installed to work on locally - as an example, one requires Helm, Helmfile, sops, several Helm plugins, Pluto, Kubeval and the Kubernetes CLI. Because I don’t hate future me, I want to ensure that I’m installing specific versions of these tools rather than just grabbing whatever happens to be the latest version. I also want to ensure that my CI runner grabs the same versions, so I can be reasonably sure that what I’ve tried locally will actually work when I go to deploy it.
My current solution to this is a big ol’ Bash script, which works, but is kind of a pain to maintain. What I’m trying to find is a tool where I:
- Can write a definition, ideally somewhere shared between projects, of what it means to "install tool X"
- Include a file in my project that lists the tools and versions I want
- Run the tool on my machine and let it go grab the platform- and architecture- specific binaries from wherever, and install them somewhere that I can add to my $PATH for this specific project
- Run the tool in CI and do the same - if it can cache stuff then awesome
Linux support is a must, other platforms would be nice as well.
Basically I’m looking for Pythons’ pip + virtualenv workflow, but for prebuilt tools like helm, terraform, sops, etc. Anyone know of anything? I’ve looked at homebrew (seems to want to install system-wide), and VSCode dev containers (doesn’t solve the CI need, and I’d still need to solve installing the tools myself)
degen@midwest.social 11 months ago
Is this Nix bait? Cause I’d say Nix.
RegalPotoo@lemmy.world 11 months ago
It wasn’t intended as bait, and TBH I’d forgotten that Nix existed outside of NixOS. Something for me to look into I guess
superb@lemmy.blahaj.zone 11 months ago
I’d say Nix as well!
RegalPotoo@lemmy.world 11 months ago
Very briefly playing about with Nix it does seem pretty compelling - only issue I can see is I don’t seem to have a straight forward way of installing a specific version of a tool from the official repo - you get whatever the current version is that the package maintainers have published for the specific snapshot you are using. I guess I could maintain my own packaging for different versions if it turns out to be important
chameleon@kbin.social 11 months ago
You can hardcode a specific version of nixpkgs, instead of a branch. With the new Nix CLI & flakes enabled you can do something like this:
That's the commit I'm seeing for
nixos-23.11today, and it should still give you that exact version of cowsay years from now.Of course, the better option is to make a dev shell with flakes. Flakes come with a lockfile builtin that accomplishes the same effect, and there's no problems having different projects on different lockfiles/versions. It's a bit more work to learn, the Zero to Nix tutorials are pretty decent at teaching and come with examples though (ultimately most things are ~30 lines of boilerplate and a list of packages that you want).
degen@midwest.social 11 months ago
I only started diving into nix this year so I’m still learning, but yeah, I’m pretty sure the lack of granular versioning is a common pain point with nixpkgs. I’d suggest checking out flakes if you haven’t already, but be warned, it gets hairy lol
jeffhykin@lemm.ee 11 months ago
Use this!!
ericjmorey@programming.dev 11 months ago
If you’re using the Debian “no Frankenstein” approach, you’re limited to what is packaged, but if you do your own thing, you can have it build/install whatever you want.
metacat@programming.dev 11 months ago
Nix is interesting and fine if you are a solo developer with time to learn the details. I did try it briefly but find the learning curve of rtx is near zero - it does less than Nix but is very easy to adopt in a team. Compatible with asdf but faster and easier in some way, and actively developing.