Rejoinder: the problem with conda-forge right now

** Thu 21 April 2016

Summary: I raise some follow-up points to yesterday’s post on community-governed packaging efforts.

The problem with conda-forge today

As discussed in my blog post yesterday, conda-forge may offer the way forward to create a community-governed package repository that meets the standards already established in the Linux, R, and other open source communities.

The single biggest problem with conda-forge right now is that its hosting of build artifacts depends on closed source software and a proprietary hosting service, anaconda.org (formerly binstar.org). To continue the Linux analogy, it would be as if software for creating apt or yum package repos were closed source. It’s much better than not having any hosting service available, but it would be better to have a option available that is open source and under community governance. You can see how this works in the Debian / Ubuntu ecosystem, for example.

The same type of software used to create anaconda.org and the on-premises product analogue (which Continuum sells to enterprises to run on their own servers – so their own closed-source software can be conda-installed behind firewalls) is also needed to create a network of publicly available package mirrors. See R’s CRAN mirror network for an example of what this might look like.

Summary

Solving the community-governed binary packaging problem completely requires the non-trivial task of creating an open source conda build artifact server in addition to the problem of operating shared build and test infrastructure.