Recently I've been thinking about operational risk (op. risk). Operational risks arise from failures of processes, for instance a missing email, or an automated software system not running properly. Many commercial institutions are interested in minimizing op. risk, since it is risk that produces no value, as opposed to risks associated with investing. This is also something I think about in my job at Lab49, where I'm a software engineering consultant focusing on financial institutions. I think there is also a good analogy for Conda-Forge, even though we are not a commercial outfit. In this case the risk we incur isn't the potential for lost earnings but frustration for our users and maintainers in the form of bugs and lackluster user experience. In this post I explore three main sources of operational risk for Conda-Forge: Automation, Top-Down Control, and Self-Service Structure.

conda-forge now supports PyPy3.6 as the python interpreter in a conda environment

Supported platforms are,

• Linux-x86_64 (glibc 2.12 or newer)
• OSX-x86_64 (OSX 10.9 or newer)
• Linux-aarch64 (glibc 2.17 or newer)
• Linux-ppc64le (glibc 2.17 or newer)

The main goal of the Skeletonr is to conquer Grayskull.

Introduction​

All jokes aside, the new project grayskull was created with the intention of generating better Conda recipes that would allow to package properly projects available in different channels such as PyPI, CRAN, Conan, GitHub register, GitHub repositories and so on. On top of that, Grayskull is also being developed to help conda-forge to update recipes.

The conda-forge "autotick" bot is a crucial part of conda-forge's infrastructure. It enables automatic maintenance of conda-forge packages by pushing version updates to the underlying software and enabling large migrations of packages from one dependency to another (e.g., Python 3.7 to Python 3.8). As conda-forge grows in size, with over 9,000 packages to date, automatic maintenance of the conda-forge ecosystem will become even more important.

Handling application binary interface (ABI) migrations has always been a hassle for Conda-Forge. Maintaining ABI consistency helps enable the "just use conda-forge" experience for many of our users, making certain that numpy's blas is the same as scipy's. As libraries update their code, the new versions may be ABI incompatible, as function signatures and other symbols may have changed, leading to the dreaded SegmentationFault and other errors.