Package management is a significant issue in every programming language and the number of packages associated with each language is astonishing. Python’s PyPI just reached 100,000 packages, RubyGems has 125,000, and Node.js’s npm is over 450,000. While the extended capabilities these packages provide is a major source of technical innovation and strength for the language, it also brings complexity, dependencies, and scale issues.
Early in a language’s development, there comes a time when a central package authority makes considerable sense as the scale of the number of package options grows too large to easily search, discover, and retrieve. Downloading each piece individually and attempting to rationalize versions and dependencies becomes a larger and larger pain point. To solve this, each language community has gone the route of building dependency/package management tools and building out a centralized package repository. The only exception recently has been Go, where the community is working on a first class dependency management tool, and hasn’t landed on an official repository for packages as yet.

We’re Taking a New Approach

At ActiveState we have been involved in the Perl, Python and Tcl languages for almost two decades, and in all cases, it made sense for us to build a package repository and tools for the language. We filled a real gap in the community and this was vital to the value we could bring to our clients. However, times change…communities evolve, get stronger and serve more varied interests and we strongly support this across all open source languages. As a result, ActiveState is taking a new approach to package managers for ActivePerl, ActivePython, ActiveTcl, ActiveGo, and our upcoming languages distributions ActiveRuby, ActiveNode, and ActiveLua.
It is our belief that a less fragmented package ecosystem is healthy for a language, particularly as it scales. It doesn’t mean developers have to use it or must publish the code they wish to share in this fashion, it just means that for the majority there is one place their project can be found, and that’s where it will have the best chance to get into the hands of other developers. This is a win for the entire community. With this in mind, we are making the shift to using community-based package management tools and services moving forward in all of our distributions.
For our users this means that package management tools in all of our distributions will be focused on the community-recognized package managers. In the case of ActivePython, we include pip and will discontinue our own PyPM. In ActiveTcl we will continue to support Teacup and Teapot, but we are planning to open source those pieces that are not already in the community at large and will continue to support the hosting of those services for the community. In ActivePerl we have the Perl Package Manager, which we will continue to maintain as a source of pre-compiled modules (for now) but we also ship with CPAN support. In our upcoming Ruby distribution, we will use RubyGems for gem management. In ActiveGo we are looking forward to the dep project (https://github.com/golang/dep) reaching a stable release. We didn’t feel it was wise to pick a single Go package solution as yet even though there are several good ones depending on your use case. For ActiveNode we expect to use npm and ActiveLua will likely be based on LuaRocks.
These language ecosystems are a wonder to behold…the dynamism and innovation never fail to amaze me. Community centralized package management and the tools to consume it helps share innovations far and wide. I encourage you to support and thank the maintainers of these package infrastructures as they are providing a tremendous benefit to everyone.