I know there choice of distro is really meaningless as you can install almost any program on almost any distro. But I have been playing with kali which is for security people and pen testers. Is there a similar distro for programmers? Like a few ides installed some profiling tools some virtual environment tools etc?
Distro packages don’t really matter much in my experience. You either use project-specific package management or install stuff with Homebrew or Nix package manager. Sometimes maybe even containers.
One problem with distro packages is that you can only install one version. And in practise a lot of software projects have outdated dependencies. Sometimes you have multiple projects with conflicting version dependencies.
This isn’t technically true for all distros—Gentoo has a mechanism that will allow multiple package versions to be installed in parallel. I have multiple distro-packaged Python and Lua interpreter versions on my system, for instance. But it does require some extra work by the packager, so it isn’t done universally for all packages.
Are these made similarly to how Debian handles python2 and python3 for instance?
I’m not sure that anything short of a package manager that would compile everything from sources would be able to provide capability to pick and mix specific package versions.
I don’t know how Debian’s solution works, so I couldn’t say for certain. Gentoo usually installs the different package versions to their own directories, and there are methods for selecting a “system python” (or lua, etc) which is the target of the
/usr/bin/pythonsymlink. Other versions have to be called with qualifiers (for instance,python3.10). Python libraries installed through the package manager may install to one or several versions depending on the content of a couple of environment variables, and applications that need python can request a specific version if they need to, or accept the system python if they don’t care. (Note that python2 is no longer eligible to be the system python—you need at least one python3, although 2.7.18 remains in the package repository and can be installed as well if you really need it.)Of course, if you’re not a programmer, you can leave the defaults for everything alone, and most of the time it should Just Work.
Sounds pretty close to Debian as far as I remember. In Debian those symlinks are called alternatives, and can be configured with update-alternatives. Not sure about the Python libraries though.
deleted by creator
Well, now you are hitting on my real recommendation which is to use Distrobox. Distrobox allows you to install multiple userlands that are all isolated from each other but all seem native on your system and give you full access to shared files and resources ( even the GUI desktop ).
It is very common to work on something not that just has outdated packages but that targets a specific distribution. If you are building something that will target an Alpine container in the cloud, it is handle to create an Alpine Distrobox to have all the same libraries. Similarly an app might target a specific version of Ubuntu. One of the products I worked on last year was based on Ubuntu 18.04. I could easily create an Ubuntu 18.04 Distrobox to work on that.
Distrobox also means I can prevent the build-up of cruft from all the little specialty tools and dependencies that projects require that I will not need long term. Remove the Distrobox and remove all the junk.
This is different than pure Docker to Podman though since Distrobox still gives you full access to your base system. You only have to install what you uniquely need in Distrobox. So i am not necessarily installing all my tools in Distrobox. Just the specialty ones.
Anyway, this is a more complicated answer and setup. In my view, the host environment still matters a lot and what I said above still stands.
Heh, Distrobox came to my mind when writing my comment. I haven’t used it enough to recommend it yet though.
I recall there are some other development container projects, but can’t remember the names right now.
Development containers are nice in theory. In practice, sometimes development environments are so complex that it might not be worth the trouble. But it’s good to have options.