Programming

17668 readers

215 users here now

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

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

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

[email protected]

Tool to manage CLI tools (lemmy.world)

submitted 1 year ago by [email protected] to c/[email protected]

9 comments fedilink hide all child comments

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)

all 10 comments

sorted by: hot top controversial new old

[–] [email protected] 0 points 1 year ago (1 children)

I have no knowledge in this area, but this really sounds like containers territory (Docker, not VSCode) ?

[–] [email protected] 0 points 1 year ago (1 children)

Dev containers is a Docker container under the hood, it's just some tooling to make it slightly easier to set up - same objections, if I'm using Docker, I'm still stuck with a gross script, just that it's running inside the container rather than directly on my machine

[–] [email protected] 0 points 1 year ago* (last edited 1 year ago) (1 children)

What do you mean? I containerize my tools, and write a docker file to install everything. The dockerfile is just something like:

FROM ubuntu:22.04

RUN apt-get update &&
apt-get install -y helm pluto kubeval etc

How is that gross?

[–] [email protected] 1 points 5 months ago

Just had the same setup and that project was randomly breaking as some dependencies were not quite stable upstream. If you do this, please pin the versions like so: sudo apt-get install apache2=2.2.20-1ubuntu1 or you'll have fun debugging in the future ;) But I think something like nix or devbox would be better overall.

[–] [email protected] 1 points 1 year ago (1 children)

Is this Nix bait? Cause I'd say Nix.

[–] [email protected] 0 points 1 year ago (1 children)

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

[–] [email protected] 0 points 1 year ago (1 children)

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

[–] [email protected] 0 points 1 year ago (1 children)

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

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

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.