Uwe’s Blog

Should I write that AI coding strategy post?

2026-02-05T00:00:00+00:00

In the last two months, I wanted to get people to experiment more with agentic coding tools. While I have seen successful uses of them, some people still weren’t using them at all, and others stuck with one tool (mostly GitHub Copilot) and assumed that all other tools were similar. Given the changes we are currently observing in the software engineering space, the level of experimentation I was seeing at our company was lower than I would have expected. Still, there is a large crowd trying out everything, experimenting with new techniques and constantly seeking access to new tools. These should be the ones I want to encourage to keep doing it and help them remove any blockers along the way.

Why should I write such a post?

Among other actions, I wanted to write a call-to-action blog post to encourage and streamline our efforts to adopt AI-based (agentic) coding tools. The post should not be as strong as the one from Brian Armstrong, but rather a soft version of Tobi Lütke’s post. The plan is not to reshape/reorganise the company with AI, but rather to guide it toward a sane adoption of AI coding.

Before writing the post, I had to decide whether I should do this in the first place. I wanted to include some context on the current state, discuss open questions, outline what we are going to do, and include a call to action at the end. This will turn into a lengthy post, and, from experience, the longer a post is, the less likely people are to read it in full. Still, this marks a significant shift in how we (will) work, and I was encouraged by several people to address this and ensure we move at the same pace as the leaders in the field. In addition to the length, the content can simply lead to some backlash. We are in an experimental phase and have not found the right way to do things. This means that it is pretty easy to be criticised for pushing immature practices. In the end, this is something I considered a necessary evil, as I want to push people to look into agentic coding that they are not doing as actively as I wish.

How to start?

Once I had committed to writing the post, I needed to decide what it would contain. As I wanted the whole company to be able to read it (80%+ of my colleagues write code), it needed a sufficient introduction to the topic. To start, I used Karpathy’s post from 26th Dec (you need to look it up, I don’t link to that site anymore) as an introduction. This already summarises the madness of choices/possibilities/… a programmer currently has to go through if they want to write code. In addition, I felt the urge to clarify that producing code is only a subset of the work a software engineer does. My gut feeling is that once you leave the group of people writing software, people assume a software engineer’s sole task is coding. The other elephant in the room I wanted to touch on in the introduction was the people calling for a “wait-and-see” approach, where we lean back and look again in several months/years’ time on what people converged on. While this would save us a lot on experimentation, it would also mean we would not be able to leverage the benefits for very long.

With the context set, I moved on to the company specifics. This picked up conversations from Slack and also referenced Notion pages listing the tools we have available and those we are actively experimenting with. This should directly allow people to take action and try out things that they may not have been aware of. To emphasise that we are going through a significant change, I then outline the new patterns of software development we are seeing. While you shouldn’t “vibe code” everything from now on, it is important to understand that you can successfully use it for things that you may not have thought of before. If you have the right guardrails and checks in place, you should be able to create settings/situations where you can run the code blindly. Still, there is a psychological component to it. We are used to inspecting the code to ensure it does what we intend, rather than checking it from the outside. In some cases, we need to unlearn it, whereas in others, we should definitely review and fully own it. This part is important for me to get right. I don’t want to argue that everything should be vibe-coded, but I do want to encourage people to try new possibilities where you wouldn’t have coded something at all in the past. In contrast, anything that could be considered production or critical code should be carefully reviewed using the four-eyes principle and owned by the person submitting it to a project.

Finally, I wanted to mention the more extreme approaches, such as fleets of agents or OpenClaw. While I don’t think that our software development process can benefit from them or we would trust such things security-wise, it is important to study what people are building and learning in this space. If you push stuff to the extremes, you will see what breaks, under which conditions it breaks and what actually holds. We can then apply these learnings to our processes.

Laying out next steps

Having a long introduction and providing context doesn’t help at all if you don’t take action. Thus, I continued with a section on what actions I am taking. As I’m the one doing a bold blog post, I should also be the one taking bold next steps. As this is not a purely technical evolution, I have started preparing some in-person events to talk to people. In addition, I will share more information on the topic in a virtual company-wide software engineering event. My main goal with these events is to encourage people to experiment with these tools and discuss their learnings. To enable experimentation, I not only need to encourage people but also understand what is holding them back and work to remove their blockers.

Before I jump to a call to action for the reader, I enumerate some open discussion points that go beyond choosing the right tool to how the workflow should look. This can be tied to the tools people are using, but at the moment, it seems orthogonal to the specific coding agent. While I can’t list everything that needs to be discussed, I’ve listed the most prominent and/or obvious items. As I’m posting this article internally, people can comment on it and maybe already start a discussion there or link to a deep dive on the topic. In the context of our company, there is also a major topic that would immediately lead to larger discussions, so I have added a paragraph on it before finally jumping to the call to action.

Call to Action

The final part of the blog post is then my call to action to all my colleagues. With my main objective being to have them experiment more, I start by asking them to install the most-hyped tools. While you do not need to start using them immediately, you should have them installed so that this bit of friction is removed before you encounter a situation where you could apply them later.

With everything prepared, I encourage them to consider every problem they encounter in the near future and whether they can use these tools to address it. For matching situations, I strongly suggest that they also try out vibe coding. While it isn’t a good fit for everything, there are many situations where looking at the code isn’t necessary. If you haven’t done it in practice, it sounds scarier than it is (if used appropriately).

Did I cover everything?

Given the large and fast-moving nature of the topic, it was impossible to cover everything in this blog post. I didn’t go into detail about any specific tools or techniques. These are ones that will change quite quickly, and some of them even changed during the writing of this blog post. One section I initially covered was the cost. In the end, because the section became quite long, I separated it into its own blog post and will post it in about one week. Agentic coding is not only costly because it consumes a lot of tokens, but it also involves a lot of bureaucracy in onboarding people to the new tools and conducting an information security review. Furthermore, there’s a social and psychological cost because we see dramatic changes in the way work is happening, and you have a lot of social interactions about how this should happen, and what should be done first, and where we shall wait and see what time will tell us.

Deep technical blog posts are still worth it in the AI age

2026-01-20T00:00:00+00:00

AI summaries mean that you need to click less on search results to find the actual information you’re looking for. But for me, as someone who writes a lot of deep tech in blog posts, I have seen that it’s still worth it to write the blog post, and it’s still worth it for the readers you want to read your articles to actually read those blog posts and get there with AI. You won’t reach millions, but you still reach the people you really care about.

In my example, I have triggered a bug in the macOS Linker in the conda-forge setting in mysql-feedstock#115. This is a hard-to-debug issue because your compiler is segfaulting and not reporting an error. In my case, the segmentation fault sadly led only to a very short stacktrace:

% lldb "/Users/…/arm64-apple-darwin20.0.0-ld"
(lldb) target create "/Users/…/arm64-apple-darwin20.0.0-ld"
Current executable set to '/Users/…/arm64-apple-darwin20.0.0-ld' (arm64).
(lldb) run -demangle -lto_library …
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x000000019d488a80 libsystem_platform.dylib`_platform_strncmp$VARIANT$Base + 176
libsystem_platform.dylib`_platform_strncmp$VARIANT$Base:
->  0x19d488a80 <+176>: ldr    q0, [x0], #0x10
    0x19d488a84 <+180>: ldr    q1, [x1], #0x10
    0x19d488a88 <+184>: cmeq.16b v1, v0, v1
    0x19d488a8c <+188>: and.16b v0, v0, v1
Target 0: (arm64-apple-darwin20.0.0-ld) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000019d488a80 libsystem_platform.dylib`_platform_strncmp$VARIANT$Base + 176
    frame #1: 0x00000001001c0538 arm64-apple-darwin20.0.0-ld`ld::passes::dylibs::doPass(Options const&, ld::Internal&) + 412
    frame #2: 0x0000000100013c04 arm64-apple-darwin20.0.0-ld`main + 732
    frame #3: 0x000000019d0b5d54 dyld`start + 7184
(lldb)

Given the sparse information, I felt quite lost. I am used to debugging foreign software, but this sadly didn’t yield any useful information. Still, in my effort to leverage the newly available LLM-based tools more, I pasted the stacktrace with some additional information into Gemini and Perplexity. At first glance, neither of them led to useful responses, independently of how much information I gave them. At a second look, the following (simpler) prompt on Perplexity provided a crucial hint in the sources:

I have a segmentation fault here:
 thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
 frame #0: 0x000000019d488a80 libsystem_platform.dylib`_platform_strncmp$VARIANT$Base + 176
 frame #1: 0x00000001001c0538 arm64-apple-darwin20.0.0-ld`ld::passes::dylibs::doPass(Options const&, ld::Internal&) + 412
 frame #2: 0x0000000100013c04 arm64-apple-darwin20.0.0-ld`main + 732
 frame #3: 0x000000019d0b5d54 dyld`start + 7184

I was surprised to find a reference to lucascolley.github.io. While my stack trace looks very generic, Lucas is someone I recognised due to his involvement in conda-forge. In his article, he actually mentioned that he changed the line that segfaulted for me If this had been hidden in a GitHub commit, I would not have expected Perplexity to pick it up. But since Lucas has written the blog post, I did get a very crucial hint (or possibly the solution) at what is breaking here.

This enabled me to resolve the issue in cctools-and-ld64-feedstock#103 by adding a nullptr check to the existing patch. Instead of several hours of debugging and understanding a complex codebase, this could be fixed in less than 15 minutes.

Conclusion

While AI-assisted search may mean the overall number of readers of a blog post goes down, it still exposes the right readers to the right posts. In my case, I would even argue that I would not have (re-)discovered that post if it were not for AI-assisted search. My traceback provided very limited information, and a search on classic search engines didn’t yield any results related to my issue. This makes me personally more confident in writing more of this kind of blog posts. They will not reach large masses, but actually the people I want to share my knowledge with and that could profit heavily from it.

Feature image from Pascal Meier on Unsplash

Learnings from the Python 3.14 migration

2025-12-15T00:00:00+00:00

Personally, I was keen to ensure that Python 3.14 availability on conda-forge was as good as possible on the actual release day. conda-forge’s build infrastructure is a massive benefit, and I wanted to show others how this can result in useful progress for them.

During the work on enabling as many packages as possible to be installable with Python 3.14, I came across several things that could be prepared for the next Python release to improve the overall package availability on release day.

Building Python alphas and betas

The single most important obstacle to making Python builds available is the first successful release candidate (RC) build. This can be improved by working on the RC build as early as possible. However, as the majority of time is spent updating the conda-forge-specific patches to the newest Python version, we can already minimise this beforehand.

For the Python 3.14 series, work began with the PR to python_abi-feedstock to add Python 3.14 support on July 8. This was followed three days later with a PR to python-feedstock to add Python 3.14.0rc1. This PR was merged a month later, which meant that the first Python 3.14 build was available on August 11. Four days later, Python 3.14.0rc2 was merged. On August 20, we started the migration for Python 3.14. This means we started the migration 48 days before the final release.

To prepare for Python 3.15, we already have an open (and green) pull request for Python 3.15.0a2. The python_abi PR for Python 3.15 was already merged on November 16. While there will be several changes until the first release candidate is available, building early means that the incremental changes will be smaller. Thus, building the first release candidate should take less time if we maintain a steady pace of development releases.

While working on the Python 3.15.0a{1,2} build, I also manged to make my first CPython contribution. There is a new function called types_world_is_stopped in CPython that should only be compiled in certain (debug) settings. As conda-forge’s debug build is without assertions (whether this sould be, is another discussion), we did hit an edge case which is not tested by CPython’s CI. My contribution was then to extend the C macro guard to also cover this case. As this has been merged upstream, we can drop this patch in the next alpha release and aren’t accumulated more patches for the next release (for now).

Common Problems of Package Updates

While working on several pull requests that were failing during the Python 3.14 migration, it was easy to identify patterns where packages failed to update to Python 3.14. Many packages already had failing pull requests for Python 3.13, but would have been easily migratable to both Python releases. The problem there was often that for Python 3.13, we had dropped setuptools as a hard dependency in pip. Adding the build backend (setuptools) explicitly to the host environment fixed a lot of builds.

Another change in Python 3.14 was that it was more cautious about how often the reference count is increased for an object. Thus, some unit tests were failing in different packages that checked for refcount == 2, whereas in Python 3.14 these objects would only have a refcount of 1.

In this and many other (package-specific) failures, upstream often already had a fix merged into main, but not for the current release. Thus, to get a Python 3.14 build for the currently released version, one needs to backport this fix. My approach to get this working is by adding an exit 1 to the top of the build script and then running the build. Once the build hits the exit 1 in the script, it (obviously) fails. Then I can cd into the work directory of the current build and add the downloaded source code into a temporary git tree using git init . && git add . && git commit -m "Initial commit" --no-verify --no-gpg-sign. The upstream fix can then be obtained by adding .patch to the URL of the commit or pull request on GitHub. By using git am --reject <patch>, we can add that patch to the git tree and fix any conflicts that occur. We can then use git format-patch --no-signature HEAD^ to generate a clean patch that we can add to the recipe.

Dealing with (half) abandoned feedstock

As not all feedstocks are actively maintained, conda-forge/core can step in if a contribution has waited at least seven days for a review from the maintainer (there should be an explicit ping!). Many Python 3.14 pull requests were immediately successful; however, the maintainers were inactive. Thus, I manually reviewed them and explicitly notified the maintainers that they appear to be fine for merging. For a future release, it would be nice if the autotick bot could also automatically ping maintainers if a pull request has green builds, a CI entry for Python 3.x and has been open without any interaction for Y days. Then, conda-forge/core would only need to review the PRs that are at least 7-10 days old and have passing CI.

The seven-day waiting period on these PRs is a bit annoying if you want to ramp up the Python 3.x builds extremely fast, but given that we merged most dormant PRs 20 days after the final release and got the major packages (with dormant maintainers) in before the final release, we were already quite successful. One thing that would have helped me a lot in pinging dormant releases would have been to see the CI status for each pull request directly on the status page. While writing this post, showing the CI status in the migration table was contributed by someone to conda-forge.org.

Major nodes in the migration path

There is a limited number of central packages in the migration path. While there are some basic ones, such as setuptools, that are used by a huge number of downstream projects that already have Python 3.14 support early on, there are other packages that are not that early with it. Examples for this are pandas, numba and pytorch. These stood out as the packages that were (and still are) at the top of the list of important packages to migrate on the Python 3.14 migration status page. The earlier we hit those packages, the quicker we can also provide feedback to upstream on what works and what doesn’t. Similarly, in some cases, upstream actually uses a conda package in their CI. With us then hitting them in the migration tree, they often can start adding a Python 3.14 job to their CI, as all their dependencies are now available.

Even if they don’t use conda packages in their CI, and we cannot provide them with additional information on failures, hitting them faster ensures that we know that we will need to spend some time on them quite soon. This means that we can, in the meantime, invest in ensuring they are on the latest release and that the recipe meets modern standards.

Preparing for Python 3.15

While Python 3.14 was the release with the best availability curve on conda-forge, we want to ensure it is surpassed by the next release. Thus, we can already start preparing for the Python 3.15 release now. The most obvious one is starting to build Python 3.15 pre-releases as early as possible. This also enables us to submit patches upstream to CPython instead of keeping them local to conda-forge.

In the initial phase of the migration, CI is typically overloaded by the number of pull requests opened. Consequently, the queue often becomes so long that the migration needs to be paused, allowing the remaining work on conda-forge to continue. Thus, in this initial phase, we should ensure that the packages migrated first are all using rattler-build to minimise resources as much as possible.

Before we even start the migration, we can also migrate some packages for the upcoming Python release. Often, packages don’t need to be specific to a Python release. Some packages can be marked as noarch: python if they don’t contain any binary code at all. This is not possible for all non-binary packages, but over the years, we have extended the mechanics of noarch: python to accommodate many cases that could not be converted previously.

If packages contain binary code, they can still be built for a new Python release if they only utilise the limited API. The support for such packages (ABI3) is relatively new in conda-forge and thus seldom utilised. For example, most packages that use Rust code are actually ABI3-compatible and could be marked as such. This would also ease the load on CI in general, as the Python version matrix would be reduced to one entry per architecture.

Personal Efficiency gains using AI (Dec’25)

2025-12-08T00:00:00+00:00

In recent times, it has become common for people to post about how they’re becoming more efficient with the use of AI. I want to follow that trend and also provide a quick overview of where I’ve been using AI in my workflow over the last months to ensure I’m as efficient as possible. Some of the gains have been in place for months; some of the things I’m using are actually ones I discovered in the last week, and make me a lot more productive. Sadly, there are still many places where I wish I could utilise AI to be a bit more productive, but we’re making progress.

Writing Text

Writing text, especially in English, is one of the most common activities I engage in during my daily work. For that, I have been using Grammarly for a long time to correct many of the grammatical mistakes I make as a non-native English speaker. This has helped me improve significantly, both in the end result and in the text I write before it gets corrected.

Additionally, I’ve switched to using WisprFlow to dictate some of my text. This is particularly useful if you need to write large chunks of text without typing them, or if you’re on the go and only have a mobile phone. Then typing the amount of text will be really a hassle.

Sadly, what Wispr is going to add as text is not perfect, so especially for blog posts and longer content, you need to review it once or twice. Besides some typos or misspelt words, especially things like programming-specific abbreviations, are not well matched and often can’t come up in a quite weird way. Still, some of the typical ones, like MCP, are perfectly recognised by Wispr. There is always a pass with Grammarly required afterwards. Luckily, LLMs are not very picky about the correctness of your text, and thus, this works perfectly for prompting them.

Research

My web search has shifted mostly to using Perplexity if I need a piece of information. I can type in a rough search statement and don’t need to worry about using the correct terms to get a match. Instead, Perplexity is quite good at finding search terms that match my question very well. In comparison to other LLM-assisted web searches, Perplexity is much more snappy, and I also perceive their citations as a lot better. For things where I know exactly what the terms are, I’m still sticking to Google, as a simple web search is much faster. This is particularly true for shopping; here, I often already know exactly what I want and thus don’t really need or want AI assistance.

If I want to conduct in-depth research on a topic, I often start by searching using both the standard and deep research features simultaneously. Often, Deep Research leads to a much better understanding of a topic than a quick web search; however, there have been several instances where Deep Research took a peculiar turn and presented me with a lot of information that was tangential to my question but not at its core. In these cases, the normal search feature of Perplexity actually led to a much better answer.

My most common usage for Perplexity is actually looking up solutions for error messages. Due to my work on conda-forge, I frequently encounter errors in third-party software. This also happens in using this software during development. While a standard LLM can often reason quite well about software errors, it is limited by its training dataset. My errors are in over 80% of all cases connected to software releases made in the last two months. Thus, if you do a web search and even include the version changes, the explanations for possible fixes improve drastically.

LLMs in software development

The most common area where LLMs have brought improvements, as a software engineer, is in coding. Due to my role as a manager, I no longer make significant contributions to larger codebases. With that in mind, someone who does such work might use a completely different stack.

While still a significant chunk of my work day is spent on github.com, I rarely use GitHub Copilot. In most cases, there is a tool that does the job better for me. Better in this case could mean faster or with a better UX. I have not yet compared the quality of each of these tools, as in my cases, there have not been significant differences on this side.

Producing new code is a small part of my workday. With LLMs, the share of time I spent on this didn’t change; simply, the amount of produced code increased. This is mainly due to me now letting Claude Code write a lot of small automation scripts that ease tasks that I never considered automating before. These tasks don’t take that long, and without the LLM-assisted coding tools, I would have probably taken up an hour or more to write the automation. With prompting, reviewing, and testing these automations, the time required is now typically within a maximum of five minutes per task. This makes many more tasks in my daily life worthwhile to automate.

If I do make a more significant change in a codebase, I tend to use Cursor. The UI allows me to review the proposed changes more effectively than in a TUI like Claude Code. It also has the advantage of being significantly faster than GitHub Copilot. Its speed is one of the surprising aspects/benefits of it. Many of my colleagues initially seem reluctant to try out Cursor, as it looks similar to Copilot, but they are then positively surprised by its speed.

If I want to understand large code bases and use the model for querying them, I switch back to Claude Code. This is mostly due to my love for the terminal (I’m a NeoVim power user), but also because of the distraction-free presentation of everything in Claude Code. Querying a codebase in my workday can involve either finding a specific functionality within a larger codebase or initiating a larger review of the codebase. For the latter, you need to structure the prompt according to the type of review you want to conduct. However, it really helps to break down a project into segments, build an understanding together with the LLM, and ask more specific questions in certain parts of the code. Here, better documentation or a good CLAUDE.md (which is essentially documentation) really helps to achieve better, more targeted results.

LLMs (not a particular one) are great at finding the actual error in a very large CI log. While these errors generally occur at the end of a log file, they are not always at the very end, as some cleanup occurs once the actual job fails. Additionally, there are many cases where a single core error occurs, but multiple exceptions are raised on top (e.g., in the case of a failed compilation) that obscure the search for the initial failure. Using an LLM can save you anywhere from 30 to 60 seconds, but if you do this often or in an automated fashion, the time savings also add up. LLMs can then also help and explain the reason for the error. In the case of some C++ errors, this also helped me to understand which line actually explained the error. For certain failure scenarios, this is sadly non-trivial to understand.

If the error is in code I’m working on, I usually switch to local development using Claude Code and let it figure out how to fix it. If the error occurs in a third-party tool (as is the case in my conda-forge work), I’ll use, as mentioned above, LLM-assisted web search to obtain a suggestion on how to resolve it.

The combination of LLM-assisted error detection in logs and web search for finding a solution to the problem works so well that I have used it as an onboarding task for an intern. This is a neat project that allows one to learn the frameworks for dealing with LLMs, understand how different LLMs yield different results, and identify the engineering challenges that arise in this context. One of the findings we observed was that the mini variants of the most common LLMs identified errors in the log file; they only listed a set of errors, whereas the larger models continuously pinpointed the actual error that caused the failure and could extract that specific information. We look forward to sharing more information on this soon.

Summary

Overall, LLMs help me to solve a lot of small things more efficiently in several areas. There is not one single thing that they have made a massive difference in. It’s challenging to quantify the improvement, but overall, it has a very noticeable and positive impact on my workflow. While many things are faster now, I also get distracted by them, as I want to see whether they can solve other problems or spend time understanding how they work.

My general takeaway from all the experience I gained with using LLMs in my daily work is that you should be in a constant testing phase. New tools or models appear on a daily basis and can help solve some challenges in a different way. Without a testing routine, it is hard to follow, and it will also be hard to catch up. I don’t think that it pays off to wait until the “dust has settled” and until clear techniques have emerged that don’t get updated so frequently. You will need to catch up on all the development anyway, and that won’t be easy if you don’t do it incrementally. At the same time, if you wait and don’t constantly test new things, you will also miss out on a lot of efficiency gains that (accumulated) make an enormous impact on the daily work.

Python 3.14 Availability on conda-forge

2025-12-01T00:00:00+00:00

As I was intrigued by @hugovk’s BlueSky post on usable Python 3.14 packages on PyPI, I wanted to see how the situation is on conda-forge. Here, we have a different setup where central tooling pushes even more towards availability.

While for wheel builds cibuildwheel will already nudge the majority of upstream maintainers to build wheels before the release, on conda-forge, we have an even more intense nudge by the regro-cf-autotick-bot opening PRs Rebuild for Python 3.14 on packages where all dependencies already support the new release. This makes it even more noticeable for maintainers that they can build their package for Python 3.14.

In contrast to PyPI, the people responsible for the Python 3.14 builds are different. In the PyPI case, the workload is on the upstream maintainers of a package to add Python 3.14 builds. In conda-forge, you have feedstock maintainers (who sometimes include upstream maintainers) and eager contributors who would like to get a working Python 3.14 environment as soon as possible. If people are looking at more than a single artefact, they will gain a better understanding of how to resolve failing builds for a new Python version.

When do packages get “available” for a new Python?

As outlined in the conda-forge blog post about the Python 3.14 release, builds for the new Python version began once the first release candidate was available. These packages are not yet immediately available to the end-user as the python package itself is not released to the main channel, but rather in the label conda-forge/label/python_rc. By putting the Python release (actually, we let the package depend on a metapackage in that channel) behind a label, we can ensure that end-users don’t accidentally get a Python 3.14 environment. Once the main Python release has happened, all packages built for Python 3.14 become immediately available, as there is now a python package without a dependency on this magic label.

Packages that are designated as noarch: python or those built as ABI3 packages on conda-forge don’t require any modifications or rebuilds to become usable. There, the old releases are already suited for Python 3.14 and can be installed once a python build is available. For a new Python version, we only need to rebuild packages that have a dependency on the minor version of Python, so-called arch-specific packages.

Availability in the first 100days since a release

To assess how quickly Python packages become available in conda-forge, we want to examine the speed at which we have built binary packages in the first 100 days since the final Python release. We will also investigate how many packages were actually built before the final release, so that we can determine whether we can leverage the availability of release candidates.

If we have a look at binary Python packages that were built once a python build was available for the currently (conda-forge) supported Python versions, we get the following plot:

If we compare the Python 3.14 line to the rest, we see that growth began much earlier than for the other Python versions and that, at its current state, it has also progressed much further before the 100-day mark than any other Python release has yet achieved. There are also three pivotal points you can see:

About 40 days before the final release mark, the migration really started. Some crucial packages were finally migrated to Python 3.14, allowing us to migrate a significant number of packages.
About five days before the final release, pandas had been merged, and then a lot of other downstreams were available for migration.
About 25 days after the Python 3.14 final release. There have been days when I spent time reviewing numerous open PRs and merged many of them. These were ready and could be merged, but the maintainer didn’t have the time, or the feedstock itself was stale, and it needed someone from core to actually review and merge them.

If you examine the Python versions over time, we can see that with new Python releases, we were able to utilise the availability of release candidates much better and could start building binary packages much earlier. At the same time, we can also see that the later Python releases actually had fewer packages built at the 100-day mark. This is not actually due to the community being less active, but there are two additional reasons that enabled us to migrate packages for a Python version early, without actually building them for the specific Python release. We will examine these reasons in the next paragraphs.

Migrating packages for new, unavailable Pythons

Building Python-version-specific binary packages requires us to have the Python minor release available; however, there are also other mechanisms we can use to build a Python package that may contain binaries to ensure compatibility with future Python releases. Many packages on conda-forge are actually accidentally Python version-specific, but can be converted with some trickery into noarch: python packages, which are then usable for future Python releases. If we examine packages that were binary packages in Python 3.10 and later migrated to noarch: python, we can see that in later Python minor releases, packages were even faster available.

Marking a package as noarch: python works if the package doesn’t contain any binaries. If the package actually contains binaries that are specific to Python, there’s still a trick that a lot of those can be ABI3, which means they’re compatible in binary form with many Python minor releases, as long as they use the limited ABI. Python 3.14 continues to be ABI3 compatible, and thus we can utilise all the packages that were built for ABI3 immediately with the availability of Python 3.14.

If we count in ABI3 packages and noarch: python packages that were once binary packages, we can see that the Python 3.14 release was the fastest ever in availability in conda-forge’s history. With these things in mind, we hope to have an even faster Python 3.15 availability.

Disclaimer: I mentioned a BlueSky post in the beginning. This has only inspired me, but sadly, the numbers here are not comparable to those because they look at the general marking of packages being available as Python 3.14. Whereas we’re looking in this post about the availability of binary packages for Python 3.14. In the BlueSky post, packages marked as noarch: python wouldn’t be counted towards availability, but only those where you explicitly add Python 3.14 support.

Learnings from five weeks of conda-forge logging

2025-11-24T00:00:00+00:00

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.

2025-41: A week in conda-forge

2025-10-20T00:00:00+01:00

This week was the Python 3.14 release, and it will also be the final week where I log my conda-forge work. While it is interesting for me to see what I do work, it is also additional work that keeps me from contributing to conda-forge itself. Still, as a follow-up, I will write at least one more post that reviews the kind of work I have done in the last weeks and how that could be made more efficient.

It started this time with a simple merge of updates for pre-commit hooks in conda-forge-repodata-patches-feedstock#1091. go-feedstock#300 and onnx-feedstock#136 were similarly trivial merges. In addition, I merged deepsearch-glm-feedstock#8 and lighttpd-feedstock#45 because the maintainers didn’t react on a ping for over a week. A new release of pdm also required a rebase of the patch we keep in conda-forge in pdm-feedstock#155. While I was at it, I took the opportunity and converted the feedstock to a v1 recipe.

A colleague of mine wanted to update the nodejs version for code-server, but code-server-feedstock#134 failed as the feedstock was still using a manually pinned docker image. Later this week, we also needed to trigger a rerun of the CI jobs in code-server-feedstock#135. This failed because of a virtual package issue in rattler-build for cross-compiled packaged. This was fixed in the meantime using rattler-build 0.48.1, and thus the rerun succeeded.

In another “support case” for my colleagues, I added types-aioboto3 to conda-forge via staged-recipes#31182. Some other typing dependencies were outdated and thus, I have converted the recipe to the v1 format and added myself as a maintainer in types-s3transfer-feedstock#11 and types-aiobotocore-feedstock#13. Once these were merged, I backfilled the feedstocks with the releases that meanwhile happend and activated automerge on them.

This week a lot of new releases came in that needed some work. There was a new DuckDB release. The Python part was dealt with in python-duckdb-feedstock#131 whereas for the C++ part, we first finished the work on getting 1.4.0 built in duckdb-split-feedstock#42 before we rebased the PR for 1.4.1 in duckdb-split-feedstock#43. This week was also the release of LLVM 21.1.3. I’m trying to also look a bit after those as I’m not so experienced with them yet, but appreciate the existence of a well-maintained compiler toolchain. I set up the tracking issue in clang-compiler-activation-feedstock#172 and merged llvmdev-feedstock#349. I couldn’t continue on my own, though, as all the outstanding PRs were dependent on libcxx-feedstock#250 to be merged. I’m not a maintainer on that feedstock, though.

Not only was Python 3.14.0 released this week, but there was also a long list of maintenance releases for the older Python versions. I opened PRs in the python-feedstock for 3.13.8, 3.12.12, 3.11.14, and 3.10.19.

Lately, there have been numerous mark as broken PRs from sagemaker-code-editor-feedstock, e.g. admin-requests#1701. This led me to review the feedstock and discover serious issues, which I summarised in sagemaker-code-editor-feedstock#193. Hopefully, they will address these soon so that the packages there have the usual code quality.

Python 3.14

With the Python 3.14 release coming up this week, I did a last push to get some packages built before the “finish line”. The most major one here was that we manually marked pyarrow as done so that the migrator progresses to its dependencies in conda-forge-pinning-feedstock#7830.

To document the progress we made this time with Python 3.14 support on release day, I wrote a blog post in conda-forge.github.io#2618 that we published on Thursday, two days after the release. As with all rushed things, there were some cosmetic changes afterwards. We did add a link to migration status early in the text and the link to the release announcement was missing.

I spent some time debugging the uwsgi builds in uwsgi-feedstock#99, but gave up because I seemed to be doing something wrong there. At least, I got jaxlib-dependent packages unblocked by fixing jax-feedstock#179. sqlalchemy-feedstock#191 could be merged as this is one of the feedstock, and I was allowed to merge the migration even though I’m not a maintainer. py-rattler-build-feedstock#7 could be closed as it is an ABI3 package and doesn’t need a rebuild.

Pinged the maintainers on fisher-feedstock#33 and fastbencode-feedstock#9. Also, this week, I was polishing the reports from weeks before. This meant that I also came across some PRs where the maintainers did not react for over a week. I have merged these accordingly.

2025-40: A week in conda-forge

2025-10-16T00:00:00+01:00

This week was the week of PyData Paris and a public holiday in Germany. At the same time, my usual day-to-day work had to continue, so my conda-forge interactions were limited to simple (but many) reviews, fixes and merges. Larger changes have to wait for the next week(s).

As there was no maintainer response for a week, I merged grep-feedstock#17 and lxml-feedstock#105. As r-base-feedstock#386 was merged, we could trigger a re-run (and merge) on r-rjava-feedstock#50. After the latest merge, the nodejs build on osx-arm64 no longer fit into the six-hour timeframe on Azure Pipelines, so I started to look into a workaround in nodejs-feedstock#416. As the initial ideas didn’t lead to a good result, this will need to be reviewed again later. In the nodejs landscape, parceljs-feedstock#54 was not automerged because an outdated os_version broke the build. I cleaned up the feedstock and converted it to a v1 recipe. scorecard-feedstock#5 failed to build with invalid license issues. Here, we needed to manually download the license of a third-party dependency instead of automatically fetching it via go-licenses. On the positive side, conda-forge-pinning-feedstock#7822 was a straightforward merge.

The work on jaxlib 0.7.2 continued with the problem that the GCC headers can be different between build_platform and target_platform; thus, we needed bazel-toolchain-feedstock#26 to handle this.

Python 3.14

For the Python 3.14 migration, it was also quantity-over-quality this week as I wanted to ping some maintainers to merge PRs or at least get the clock started on PRs where I could use my conda-forge/core powers to merge after a week of no response.

During PyData Paris, the currently biggest blocker pandas-feedstock#233 was merged after upstream released a Python 3.14-compatible version. I pinged the maintainer on fastparquet-feedstock#78 directly, as this was the next one to get more nodes in the rebuild graph going. Sadly, not everything is fixable. For example, vowpalwabbit-feedstock#92 failed because it doesn’t build as it is not compatible with fmt>=11. However, moving the pin manually to fmt=10 only leads to the following error. Luckily, some easy ones can be directly merged, like tabmat-feedstock#56.

On pytorch-feedstock#420, I commented with a link to the upstream issue that we will need to wait for PyTorch 2.10. Still, it might also be possible here that we can backport some patches to the 2.9 release, as this might be simpler/faster than getting the whole of 2.10 building on conda-forge infrastructure.

In the list of larger nodes in the Python 3.14 graph, we also had pywinpty. As the PR was failing on the current version, I first tried to upgrade to the latest one in pywinpty-feedstock#64. Still, once I found out that this would require nuget and Windows Terminal to be build from source, I moved on an fixed pywinpty-feedstock#65 by setting PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 so that maturin builds for the new Python version.

numcodecs-feedstock#119 initially failed because of a missing Python 3.14 build for coverage. After a rerender of the feedstock, the build now passes, and thus I requested a review from the maintainers. This was also the case for pyfftw-feedstock#70. Similarly, I also asked a rerender for framel-feedstock#44. Sadly, in this case, Windows kept failing with MinGW compiler issues. These were solved by removing some old workarounds from conda_build_config.yaml. The build then passed, but framel’s unit tests failed, and I moved on for now. In srsly-feedstock#56 , the rerender revealed an upper pin in the package for python<=3.13. We concluded here to wait for a new release. As the thrift-feedstock looked a bit abandoned, I revived the version update in thrift-feedstock#42 and converted this to a v1 recipe to tackle the Python 3.14 migration afterwards.

There were several more small fixes I did, that I’m only summarising as bullets here:

Rebased numexpr-feedstock#75 and bottleneck-feedstock#61 as both had new releases. In both cases, the build then passed.
Requested a rerender on argon2-cffi-bindings-feedstock#12; the builds then passed.
After the rerender on mariadb-feedstock#19, the builds sadly failed on Windows. This required linking to zlib to get them to pass.
Created sip-feedstock#100 to build sip for Python 3.14 for this (older) release to move pyqt-feedstock#159 forward
Updated onnx to 1.19.0 first before attempting the Python 3.14 migration in onnx-feedstock#135. This also needed an older protobuf version rebuild in protobuf-feedstock#255
Similarly to onnx, grpc-cpp-feedstock#414 also needed the older protobuf version to be rebuilt first before it could move on. At the same time, we had to exclude some more end2end tests from CI as the runtime exceed our Azure timelimit.
kornia-rs-feedstock#22 passed, but it had an explicit skip for py>=313. After removing this, we needed to set maturin into ABI3 compatability mode to produce a wheel for Python 3.14
conda-feedstock#274 needed a rebase after a PR to main was merged, but it is still running into a cyclic dependency with conda-libmamba-solver
Requested rerender for python-rapidjon-feedstock#70 as build were failing but logs were no longer visible. Sadly the Python 3.14 builds here fail for Python 3.14 in relation to some refcount changes (similar to what was required to be fixed in pyarrow)
pyreadline-feedstock#17 required the addition of setuptools to host to become green
In contrast to most jaxlib work, jaxlib-feedstock#325 passed directly and we merged only building for Python 3.14 and reverted that with a [ci skip] on main.
python-duckdb-feedstock#130 failed with deprecation warnings that triggered test failures. After updating to a new version in python-duckdb-feedstock#129, the previous PR also passed.
We could close gz-gui-feedstock#71 simply as this is an abi3 package and doesn’t need a rebuild.

Since the one week reaction period passed, I merged the following feedstock due to inactivity using my conda-forge/core powers:

These feedstocks were merged because @ocepaf gave me the 👍 to merge green Python 3.14 PRs where he is a maintainer:

There were also several PRs where the CI passed, so that I pinged the maintainers to make them aware:

2025-39: A week in conda-forge

2025-10-14T00:00:00+01:00

In the third week of reporting on my conda-forge work, you will see how the large number of contributions happens quickly. As we’re getting closer to the Python 3.14 release, I spent some time bringing that forward.

The week started with a rust-dev update. These updates are based on a script that regenerates a section of the meta.yaml, but the PRs themselves are not yet automated. In the same weekly cleaning session, I manually closed the close aws_c_202509 migration and aws_crt_cpp0343 migration.

Last week, the libxml2 migration progressed. Unfortunately, this also meant some breakage in a few places. I spent some time debugging lxml-feedstock#105, where we need to pin to libxml2-16 2.14.x. This is much stricter than the run_exports of the libxml2 packages enforces. In the end, this was not an unstable ABI but a change in the build that occurred in the latest minor release. While the PR for the libxml2 for ibm_db passed, it sadly resulted in failing packages as it picked the system libxml2 and not the new conda-forge version. Thus, we marked these builds as broken in admin-requests#1672. We fixed the linkages in ibm_db-feedstock#87 by pinning to the old version.

As I’m a maintainer (also user) of pcre2-feedstock, I spent a bit of time reviewing the PRs that were still open on the pcre2 10.46 migration:

Pinged the maintainer on deepsearch-glm-feedstock#8, lighttpd-feedstock#45, ugrep-feedstock#15
Triggered a bot-rerun on htcondor-feedstock#316 so that the PR is rebased on the latest main. The new PR htcondor-feedstock#325 was then swiftly merged by the maintainers.
Similarly, r-rjava-feedstock#48 needed a bot-rerun and first the merge of r-base-feedstock#383 so that the older R release also could be installed with the new pcre2
Ignored the status of julia-feedstock#297, as the whole feedstock seems abandoned
Fixing grep-feedstock#17 was a bit trickier, as it needed the new release and still kept failing, as the cross-compiled tests don’t work because of a path issue. Additionally, some behaviour changed recently on macOS so more integrated gnulib tests needed to be skipped. This was fixed by backporting the fixes from gnulib-ccb60ee9 and gnulib-b49212bd
On nginx-feedstock#96, I made some progress by fixing the missing dependency on libxcrypt on newer Linux versions. Still, configure fails with an error on libxslt
uwsgi#100 fails due to bytecode mismatches in LTO code. Thus, it needs a rebuild of Python with the latest version of GCC. As Python 3.13 was already rebuilt, I made python-feedstock#815, python-feedstock#816, and python-feedstock#817 for Python 3.10-3.12.

Meanwhile, I made minor fixes in librsvg-feedstock#129 and reviewed admin-requests#1674 and sqlglotrs-feedstock#33. As some colleagues required specific versions of Netbird, I contributed that via staged-recipes#31096 and added linux-aarch64, linux-ppc64le, and osx-arm64 immediately afterwards.

As jaxlib 0.7.1 was merged, it was time to continue work on jaxlib v0.7.2. @h-vetinari already started working on this, so it wasn’t a fresh start. As part of the new version, I updated the absl third-party dependency by adding new log targets. We could also drop the GCC 15 fixes we did for 0.7.1, as they were already integrated into this release. Sadly, the compilation now takes longer on osx-64, and to get it below the six-hour limit, I changed the oneDNN build from the bundled version to linking against the conda-forge package. Meanwhile, we also attempted to migrate to CUDA 13. This sadly failed, as not even the latest Clang 21 release can build CUDA 13 device code. Still, I used the chance to contribute Clang 21 support to google-ml-infra/rules_ml_toolchain#88.

There were again several (trivial) merges I did this week using my maintainer duties or conda-forge/core powers:

conda-forge-pinning-feedstock#7772
conda-forge-pinning-feedstock#7736
conda-forge.github.io#2603
snowflake-connector-python-feedstock#197
cargo-deny-feedstock#4 (and enabled automerge)
aws-sdk-cpp-feedstock#971
admin-requests#1664
libgit2-feedstock#86
Closed aws-sdk-cpp#972 as rebuilds are costly
Merged staged-recipes#31099 for a colleague
fisher-feedstock#32
seqan-library-feedstock#12
gdk-pixbuf-feedstock#57
flock-feedstock#7
tree-sitter-sql-feedstock#6
conda-forge-pinning-feedstock#7809
Triggered cirun and then merged nodejs-feedstock#415
admin-requests#1673
conda-forge-pinning-feedstock#7793
psqlodbc-feedstock#15
Due to network issues on the apache.org side, we needed to retrigger CI before we could merge arrow-cpp-feedstock#1861, arrow-cpp-feedstock#1863, arrow-cpp-feedstock#1862, and arrow-cpp-feedstock#1864
Python 3.14

This week, I started my mini-sprint to bring the Python 3.14 migration forward so we will have a good release-day availability.

As a first step, I manually opened pymsbuild-feedstock#25, as the bot did not open a migration PR for it, but already had ones for packages depending on it. Similarly, conda-feedstock#274 failed because it needs mamba to migrate first. We could close futures-feedstock#17 , as futures is a Python 2.x-only package. I requested its archival in admin-requests#1671.

Then there was a round of PRs that could be merged, because they either were part of an abandoned feedstock or the maintainer had already approved it: cchardet-feedstock#24, flt-feedstock#14, and fake-factory-feedstock#26

For fill-voids-feedstock#6 and fisher-feedstock#30, I triggered a bot rerun because they looked good but had conflicts that prevented their direct merge.

Some PRs could easily be fixed by adding setuptools to host. Since Python 3.13, conda-forge no longer ships it as an implicit dependency of pip and thus it often breaks the build for some packages on these newer Python releases. I applied it to the following feedstocks and pinged the maintainers once the CI was green: fastbpe-feedstock#18, fastpath-feedstock#13, and future_fstrings-feedstock#21.

Finally, there is a long list of feedstocks where I reviewed the PR and pinged the maintainers as the builds looked fine:

2025-38: A week in conda-forge

2025-10-12T00:00:00+01:00

To continue to give you a glance into my conda-forge work, we’re continuing with the second week of reporting. This week was a bit leaner on my activities here as I spend my time on preparing my PyData Paris 2025.

Still, the talk also provided the need for one PR on conda-forge: I migrated the polars-feedstock to make it cargo-auditable. This has been useful as an example in my talk as polars statically links a huge number of Rust dependencies. Thus, it is a good case to highlight the existence of Phantom Dependencies (dependencies you have in your environment that your package manager doesn’t list/is aware of).

Later this week, I continued working on the jaxlib v0.7.1 PR. Here, we needed to move to clang as the default compiler on all platforms. This meant that we also needed to adjust the bazel-toolchain feedstock to also handle this. Furthermore, to work around some build issues, we had to update the bundled gloo version and the abseil-cpp dependency that we pull in as a conda dependency. Once these dependencies were updated, we got a linker error with abseil-cpp on Linux. The linker error was for a missing symbol named _ZN4absl12lts_202505124CordC1INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEETnNSt9enable_ifIXsr3std7is_sameIT_S8_EE5valueEiE4typeELi0EEEOSA_. The symbol actually existed in the source code, but was encoded in the binary as _ZN4absl12lts_202505124CordC1INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEELi0EEEOT_. The noticeable difference here is that the first contains the condition std::is_same, whereas the latter doesn’t. As this only happens on Linux, the obvious culprit here is the difference in compilers. abseil-cpp itself is built using conda-forge’s standard compiler on Linux (GCC), whereas we moved to clang. Looking at clang’s issue tracker, there is llvm-project#85656. This reveals that adding -fclang-abi-compat=17 as a compiler/linker flag solves the issues by falling back to the old symbol naming behaviour.

As part of the move to clang, we replaced not only GCC but also nvcc for compiling CUDA device code. This sadly led to one compilation error for __glibcxx_requires_subscript, which was appearing in device code, but had no respective device implementation:

In file included from /home/ubuntu/.pixi/envs/conda-build/conda-bld/jaxlib_1758038148038/_build_env/bin/../lib/gcc/x86_64-conda-linux-gnu/15.1.0/../../../gcc/x86_64-conda-linux-gnu/15.1.0/include/c++/functional:67:
/home/ubuntu/.pixi/envs/conda-build/conda-bld/jaxlib_1758038148038/_build_env/bin/../lib/gcc/x86_64-conda-linux-gnu/15.1.0/../../../gcc/x86_64-conda-linux-gnu/15.1.0/include/c++/array:210:2: error: reference to __host__ function '__glibcxx_assert_fail' in __host__ __device__ function
  210 |         __glibcxx_requires_subscript(__n);
      |         ^
/home/ubuntu/.pixi/envs/conda-build/conda-bld/jaxlib_1758038148038/_build_env/bin/../lib/gcc/x86_64-conda-linux-gnu/15.1.0/../../../gcc/x86_64-conda-linux-gnu/15.1.0/include/c++/debug/assertions.h:39:3: note: expanded from macro '__glibcxx_requires_subscript'
   39 |   __glibcxx_assert(_N < this->size())
      |   ^
/home/ubuntu/.pixi/envs/conda-build/conda-bld/jaxlib_1758038148038/_build_env/bin/../lib/gcc/x86_64-conda-linux-gnu/15.1.0/../../../gcc/x86_64-conda-linux-gnu/15.1.0/include/c++//x86_64-conda-linux-gnu/bits/c++config.h:658:12: note: expanded from macro '__glibcxx_assert'
  658 |       std::__glibcxx_assert_fail();                                     \
      |            ^

In GCC’s and Clang’s issue trackers we find similar-looking resources: gcc#115740, llvm#95183, and llvm#49727. The fix for that has been merged in llvm#136133. I have tried to apply that fix in clangdev-feedstock#383, but sadly that was insufficient as raised in clangdev-feedstock#384. The correct fix then landed in clangdev-feedstock#385:

While my plan is to get to more in the Python 3.14 migration in the coming weeks, this week the work solely focused on kicking off the build for python 3.14.0rc3.

Sadly, I ran into a bit of a mess with the AWS C stack this week. I needed to issue aws-sdk-cpp-feedstock#970 manually as aws-sdk-cpp-feedstock#969 was closed, but the bot did not retry it. Instead, the bot issued PRs to arrow-cpp-feedstock directly (see arrow-cpp-feedstock#1854). This led, in general, to a messy situation with PRs in the arrow-cpp repository. At least [main] Rebuild for aws-c* (Sep '25) seemed to have worked fine, but all arrow versions there were already in the archive (i.e. all except the latest) had some download issues, and the PRs needed to be restarted. Restarting some failed jobs in [20.x] Rebuild for aws-c* (Sep ‘25), [19.x] Rebuild for aws-c* (Sep ‘25), and [18.x] Rebuild for aws-c* (Sep ‘25) made them pass again. Afterwards, we needed to rebase the PRs (main, 20.x, 19.x, 18.x) for aws-crt-cpp 0.34.3 migration.

This week, there were also numerous small tasks I engaged in:

The build for zstandard v0.25.0 was failing due to a missing dependency on packaging during the build. While fixing this, I also converted it to a v1 recipe.
There was a contribution that added ppc64le support for cargo-auditable. The contributor first used emulation, but switched to cross-compilation on request, which made the builds much faster.
@isuruf fixed the libxml2 migration for msitools, and during my review, I realised that we were still using the old gettext outputs in the feedstock. Thus, I submitted Use new gettext outputs; convert to rattler. Afterwards, I also bumped the version to msitools 0.106.
The libxml2 rebuild for librsvg was failing with an overlinking error.
Supported people on dynare-preprocessor-feedstock#7 in their effort to build for osx-64
Commented on fmt-feedstock#67 that we should not wait too long for things to start
vega-lite-cli-feedstock#41 did not build as there was an outdated os_version section in conda-forge.yml. Thus, I took the opportunity and moved it to a v1 recipe. The sames fixes were also required to get vega-cli-feedstock#44 to work.
This week, it was also time for a rust-nightly update again. At the same time, we also merged rust v1.90.0 and then manually created the activation upto to main 1.90; dev 1.92 to enable feedstocks to use the new compilers.

And finally, the list of pull requests where I only did a review and merged them, but no real interaction:

Rebuild for libxml2 - universal-ctags-feedstock#240
Rebuild for libxml2 - libxmlsec-feedstock#40
Close out migration for vtk951
Rebuild for r_base 4.5 - xgboost-feedstock#256
snowflake-connector-python v3.17.3
miniforge-images: Bump ubuntu from noble-20250805 to noble-20250910 in /ubuntu
aws-sdk-cpp: Rebuild for aws-c* (Sep ‘25)
Migration for aws-crt-cpp 0.34.4 (incl. automerge)
Migration to s2n 1.5.26 (incl. automerge)
docker-images: Bump actions/checkout from 4.2.2 to 5.0.0 in the github-actions group (follow-up: Fix comment on pinned action)
Trigger CI on nodejs v24.8.0
Manually issued nodejs v22.19.0
Manually issued nodejs v20.19.5
Merged ibm_db-feedstock#83 and issued a bot-rerun on ibm_db#84.
symbolic v12.16.3