Fixing Ruby, Python and Node.js packaging on Debian, Redhat and variants.
Canonical URL: http://bit.ly/wtfpackages
You shouldn't be using distribution provided packages for your primary language runtime.
For you, it's your application platform, and you're the one who knows exactly which version best suits your needs. For others, it's the interpreter for another distribution-provided tool that they quite like using, such as chef or puppet. New (and stable) functionality that you wish to use happens to be saddled with changed APIs, fixed bugs and deprecated methods, all which might break those distribution-provided tools.
There is no happy middle-ground between your use case and theirs; every compromise is a poor one.
Community packages are scattered around the internet and are of varying levels of quality. One location, n versions, n languages, n distributions. Every package provided will follow the same rules (outlined below) and thus be somewhat predictable.
Community packages rarely have distribution-level support for pulling in updates. Integrate with apt & yum. Packages should be versioned/managed such that automatic system updates pull in security / bug fixes, but not entirely new versions.
Community packages often replace the distribution-provided interpreter. This causes problems with dependencies and system toolsets. Use RVM (or rbenv) and virtualenv to ensure that system Ruby & Python don't conflict with the community-provided packages.
Pre-packaging every Ruby, Python and node.js library (as distributions try to) isn't useful when you're already attaching those libraries to your application with language-specific methods.
Or, I'd rather use rubygems and bundler than dpkg to manage my application's dependencies.
Community packages age, or only work with specific distribution versions, or only work when a certain library (not listed in the dependencies) is installed. Each package's post-install script will confirm the basic behaviour of the package. Virtual machines will be used to automatically and continually install & test packages.
Use the successful homebrew + github model to manage community package contributions.
@kiall Yes, this is web developer centric .. or at least centric to organisations that control the environment they're deploying their applications to.
I can't comment properly on Python, either, it's been about five years since I've worked with Python full time.
I'd invite you to reconsider your stance re bundler & rubygems .. but I think this will only happen if you develop a large web application that requires modern libraries. It is just so much easier and flexible than having to rely on distribution libraries or having to package those libraries yourself.