"Problem statement: Currently, there is a lot of hassle and pain in dealing with non-primary (i.e. C/C++, Python, Perl) language stacks in Fedora. Although Alan wants to focus his time in the application and the actual data analysis, he too often finds himself spending time managing the language-specific toolchain needed by the application.
"Cause #1: The upstream application authors usually assume that any developer would just be using the language-specific packaging ecosystem rather that also taking into account the downstream distribution-based packaging and dependency management systems. This is a problem since there are many differences between language-specific packaging ecosystems and the Fedora way of packaging software.
"Cause #2: Many upstream applications use very brittle versioning. In other words, each application expects the user will be able to have its particular versions of the runtime, compiler and libraries available."
I work mostly with desktops and mostly in R and I've found that it doesn't pay to wait for Linux distros to package things. In fact, I'd rather compile from upstream source than have to deal with conflicts between two dependency trees. With a six to twelve month release cycle and not everything from the Comprehensive R Archive Network in the Fedora (or Ubuntu or openSUSE) repositories, I have no choice but to build the packages from upstream source. It's quick and mostly painless and easily automated on the desktop. It sometimes takes me a day or so to track down all the -devel files, but it's worth it to have fresh upstream code.
Short of going to something like Gentoo where *everything* is packaged from upstream source, I'd rather Fedora just maintain the kernel, compilers, language environments, databases and end user applications. Having totally integrated stacks like WordPress, Django, Rails or Node.js makes a lot of sense for servers, OpenShift and RHEL, but not for a bleeding edge desktop.