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)
It definitely still is. I use nix on the daily and specialize in old versions seach; Just because it’s very possible doesn’t mean people don’t find it to be a pain point.
With the right tools (which are not easily found in the docs or on Google) finding one old version is fine. Running one old version is flawless. But mixing that old version with newer versions of other packages causes problems because of the nix LD_LIBRARY_PATH issue.
I was lucky for a while too, since you can also get lucky with dynamically linked libraries.
Sometimes they find the new version of the .so (from other packages) and it works, but sometimes it finds a system .so and works until there is a system update. Which ruins the whole reproducability thing, although using the sandbox options of nix can help with this.
Nixpkgs is better about patching the RPATH now, but that’s the thing; using old versions is like going back in time. We’d need to go back in the git history and also patch the super old version.
There are tools like nix-ld which can help, but they need to be setup and they’ve got edgecases too.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
It is not? At one of my previous jobs it was nix that allowed me to get a compatible legacy version of kubectl up and running easily iirc
It definitely still is. I use nix on the daily and specialize in old versions seach; Just because it’s very possible doesn’t mean people don’t find it to be a pain point.
With the right tools (which are not easily found in the docs or on Google) finding one old version is fine. Running one old version is flawless. But mixing that old version with newer versions of other packages causes problems because of the nix LD_LIBRARY_PATH issue.
Eh so probably got lucky with the fact that the software I needed was statically linked
I was lucky for a while too, since you can also get lucky with dynamically linked libraries. Sometimes they find the new version of the .so (from other packages) and it works, but sometimes it finds a system .so and works until there is a system update. Which ruins the whole reproducability thing, although using the sandbox options of nix can help with this.
Nixpkgs is better about patching the RPATH now, but that’s the thing; using old versions is like going back in time. We’d need to go back in the git history and also patch the super old version.
There are tools like nix-ld which can help, but they need to be setup and they’ve got edgecases too.
For some reason I thought it was more annoying to work out than it looks to be. @RegalPotoo@lemmy.world you might want to check out nix-versions
Actually Lazamar’s is kind of out of date. Here’s the best sites for it:
And I made an interactive Cli tool that let’s you search all four of those simultaneously!