Comment on Tool to manage CLI tools

degen@midwest.social ⁨1⁩ ⁨year⁩ ago

• RegalPotoo@lemmy.world ⁨1⁩ ⁨year⁩ 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

  source
• superb@lemmy.blahaj.zone ⁨1⁩ ⁨year⁩ ago

  I’d say Nix as well!

  source
• RegalPotoo@lemmy.world ⁨1⁩ ⁨year⁩ 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

  source

  • chameleon@kbin.social ⁨1⁩ ⁨year⁩ 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:

    nix run "github:NixOS/nixpkgs/b4372c4924d9182034066c823df76d6eaf1f4ec4#cowsay" "moo mooooooo"
    

    That's the commit I'm seeing for nixos-23.11 today, 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).

    source
  • degen@midwest.social ⁨1⁩ ⁨year⁩ 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

    source

    • pkill@programming.dev ⁨1⁩ ⁨year⁩ ago

      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

      source

      • jeffhykin@lemm.ee ⁨1⁩ ⁨year⁩ ago

        It definitely still is. Just because it’s very possible doesn’t mean it’s not a pain point for many people.

        With the right tools getting an old version is fine. But mixing that old version with newer versions of other packages causes problems because of the nix LD_LIBRARY_PATH issue.

        source

        • -> View More Comments
      • degen@midwest.social ⁨1⁩ ⁨year⁩ ago

        For some reason I thought it was more annoying to work out than it looks to be. @RegalPotoo you might want to check out nix-versions

        source

        • -> View More Comments
  • jeffhykin@lemm.ee ⁨1⁩ ⁨year⁩ ago

    Use this!!

    source
  • ericjmorey@programming.dev ⁨1⁩ ⁨year⁩ 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.

    source
• metacat@programming.dev ⁨1⁩ ⁨year⁩ 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.

  source