Usually, I prefer manually installing the packages needed for getting started with a new language or technlogy.

I avoid using distro package managers since they tend to be a bit outdated in this regard, and specialised package managers like SDKMAN! seem overkill for one or more packages. Exceptions being languages with excellent tooling and version management like Rust or Ocaml.

I’ve been doing this for a while and was wondering what the general consensus is

Edit: Thanks for your replies everyone! I’ve decided to stick with my distro package manager.

  • delirious_owl@discuss.online
    link
    fedilink
    arrow-up
    28
    arrow-down
    1
    ·
    7 months ago

    Definitely stick to the OS package manager. Not doing this is a mistake a lot of devs make.

    Otherwise you end up with an app that doesn’t run on most systems, and expecting people to do curl piped to bash as root.

    Stick to the stable branch. Stick to the OS repos.

  • lurch (he/him)@sh.itjust.works
    link
    fedilink
    arrow-up
    14
    ·
    7 months ago

    uninstalling sometimes doesn’t work when you install from source, so i’ve learned to be patient and always use the distro package.

    • redcalcium@lemmy.institute
      link
      fedilink
      arrow-up
      8
      ·
      7 months ago

      This is why you should build a package when compiling from source instead of doing make install directly. Packages can easily unistalled or upgraded.

  • Shareni@programming.dev
    link
    fedilink
    arrow-up
    11
    ·
    7 months ago

    For personal use, I previously used system packages, but now I’m installing them through nix home-manager. It’s really nice, especially because I’ve got a list of them now and don’t have remember what to install ever again.

    • QuazarOmega@lemy.lol
      link
      fedilink
      arrow-up
      4
      ·
      7 months ago

      I’m also curious about getting Nix on non NixOS, are there any simple example home manager configurations to look at so that I can easily start?

  • sloppy_diffuser@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    9
    ·
    7 months ago

    I use Nix, even on my Ubuntu machines, to install tooling in my user profile.

    Nixpkgs unstable stays pretty up to date. The few I want something on release day or bleeding edge nightlies, I override the derivation source. I use nvfetcher to pull the latest release or head of the default branch as part of my update routine.

    I’m pretty new to Nix, so its been slow integrating into my workflow, but I plan to start integrating flake’s into my repos. My team seems to have constant issues with keeping their tooling up to date which breaks things locally from time to time.

    • brian@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      7 months ago

      one more for using nix, but for language tooling I generally prefer a nix shell and installing per project dependencies there. then updates don’t break random projects and you know all the dependencies of a given project

  • breadsmasher@lemmy.world
    link
    fedilink
    English
    arrow-up
    5
    ·
    7 months ago

    Depends what I am working on.

    Sometimes I have to work with a mess of angular and node versions, which I don’t want polluting my main system and be something to need to manage. So I use containers for development and have all dependencies for that specific project in the container

  • biribiri11@lemmy.ml
    link
    fedilink
    arrow-up
    4
    ·
    7 months ago

    +1 to running whatever is packaged by your distro. For me, Fedora is rarely out of date. If worse comes to worse, you can always volunteer to become a packager and improve the ecosystem for everyone while fixing your own problems.

  • 0x0@programming.dev
    link
    fedilink
    arrow-up
    3
    ·
    7 months ago

    Usually distro packages, even mingw and android’s sdk are packaged now (at least on Ubuntu which i’m forced to use).

    Not shying away from upstream though.

  • bionicjoey@lemmy.ca
    link
    fedilink
    arrow-up
    2
    ·
    7 months ago

    I’m a big fan of Condaforge for this sort of thing. Keeps my development software separate from my daily driving software.

  • Irdial@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    2
    ·
    7 months ago

    I run Ubuntu and use the Nala frontend for APT to keep a log of my package installs. That way, I can easily remove everything if I no longer need to work with a particular language or set of dependencies. For anything too complicated, I like to drop into a Docker container (which integrates nice with VSCode/Codium)

  • Para_lyzed@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    7 months ago

    Since I run Fedora, the repos are very up to date. Not as bleeding edge as Arch may be, but plenty fine for learning and development. There are a lot of issues you can run into during manual installation/uninstallation, so I always use distro package managers. Plus, that ensures that software has a much greater chance of running in an environment similar to an end user, so it’s just ideal overall. I can certainly understand frustrations with Debian packages being out of date, but that’s an ideological choice, and the user should have been aware of that before choosing Debian. All I usually have to do is install the compiler/runtime, a language server for neovim, and some minor configuration for IntelliSense, then I can be up and running with a new language.

    The other side to this is that you don’t necessarily need to be using the latest version of the language to learn or develop in it. It’s often a good idea to stick with the latest LTS release of the language so that it’s most available and compatible with the runtime/environment that the end user has access to. Utilizing features only available on bleeding edge versions of the language can make it difficult for others to use your software, as they’d have to go through the hassle of manually installing the latest version, and can lead to breakage if the language changes before the next stable version is released.