Hello danuke,
It seems that with every post, you open a bigger and bigger can-o-worms.
All of these software packages are designed for a Linux world. The user just runs "yum ...something..." or "apt-get ...something else..." to install software or update a system-provided version. Sometimes it works, and sometimes the user has to go back and install a newer, or older, version of Ubuntu/Centos etc. to get it all working.
There is a more "old school" way - you can install the software from source. In a really old-school way, people used to actually install test builds of newer versions, but in custom locations, just to test. Few people do that anymore. Few people even know how to build anymore.
But if you are going to use this software on a Mac, you have to adopt one of these strategies. You could go the package manager route with MacPorts, Fink, or now Homebrew and just type "brew ...something...". OS X won't let you replace system versions, so that option is off the table. That's fine though because that would surely break stuff. But you can still install from source and select exactly what versions of software you want to build with. Don't get me wrong - it's not easy. It is very difficult in fact. Each project has a different build system. Each one is designed for Linux, with Mac users being an afterthought at best, but usually a nonthought. Ultimately it is not so much building software as creatively hacking it. I have been doing that at work. It has taken me about two weeks to get the entire GDAL system built, with postreSQL, a custom Python, etc. Ideally, you should do this for any open source software you build on the Mac. Never use Apple's system provided software for anything unless you have no option. Apple DOES NOT test this stuff. Apple has crowd sourced all testing and considers it to be your job, not theirs. Apple will pluck code from an untested, development branch of any open source package and release it to 800 million customers in less than 3 weeks. I know this because I've seen them do it. It broke one of my apps.
But there is no easy solution. Each project is different. You will have to research each project and how to control where it builds from. I can help if it is something I've built lately. But I have no intention of bothering with a bleeding-edge Python3 or reliving the '80s with Tcl/Tk. I would never say this in polite company, because Python is just crushingly hip, but it *****. It is a joke compared to Perl. But I'm a pragmatic fellow so I know Perl won't get anyone, including me, a decent job. So I'll use junk Python instead because it pays the bills. That's how software works today.