Learnings from five weeks of conda-forge logging

During the last five weeks (2025-37, 2025-38, 2025-39, 2025-40, and 2025-41) I logged my conda-forge activity as a blog post. Instead of only reporting on it, I also wanted to have a look at what I have been doing there and whether things could be automated more.

One of the major points of my conda-forge output is the green contribution graph I have on GitHub. This is partly nice to look at, as it has impressive numbers, but at the same time, it is also a clear sign of missing automation. If I can manually make so many contributions, there must be a lot of them, despite a very small cognitive load. These ones are most likely to be better automated than I spending my time on them.

One of those examples where a lot of manual work is done are the migrations for the aws-c-* stack. These are the C packages that make up the aws-cpp-sdk. With the current automation, we can start migrations quite easily, which automerge for a single package. But often, the migration makes only sense if we update multiple of them at once. Otherwise, the migration of a single aws-c-* package will get stuck if another is not updated simultaneously. This typically resulted in some manual work on my part in the past. Additionally, the number of PRs when rebuilding for single packages is producing quite a bit of noise.

To streamline the aws-c-* migrations, I now have a script make_aws_migration.py that checks which AWS packages can be upgraded in the stack and submits a PR that does exactly that. To minimise the noise this generates, I will manually run this once or twice a month. You can see an example of this in Migrate for aws-c-* Nov’11.

The Go compiler on conda-forge was another source that included unnecessary manual work on my part. If patches applied successfully, it is fine to automerge the PRs there. PRs on go-activation also needed to be rerun once the go builds were done. Instead, we can use check_solvable: true to only issue the version update PR once the underlying go builds are available.

Another typical maintenance task on Go and on NodeJS is that we not only want updates for the latest release, but also for older release versions. As the conda-forge automation only supports updating the latest release on a feedstock, this has been a manual task. In the long term, it would be beneficial if the automation also updated versions on maintenance branches. As an intermediate step, I wrote (partially AI-coded) scripts (one for Go and one for Node.js) that check for version updates and issue pull requests. This could also be used for Python, but here, many more maintainers are actively subscribed to the release announcements, and thus, my scripts won’t be much faster/simpler here.

Overall, there seems to be no further patterns that I could automate. There are many small breakages that a contributor’s (and sometimes really “my”) attention is required. This includes things like packages that are already on automerge but fail due to an unexpected change. Here, my contributions won’t be overlooked, but I often find myself spending a significant amount of time scrolling and clicking until I locate the actual error in the log. This is something to work on in the future.