Looking for co-maintainers on conda-forge

I’m currently maintaining a couple of (numerical) libraries, mostly Fortran or at least with Fortran bindings, and Fortran related tooling on conda-forge and are looking for co-maintainers. While I try to involve the upstream maintainers with the packaging where possible, there are still several packages only maintained by myself:

The difficulty of maintaining those packages varies greatly, usually the CMake ones are quite straight-forward, autoconf ones are almost always a real pain (only plain make is worse) and most of the time require a lot of patching. Also, more languages usually mean more potential trouble.

Maintaining on conda-forge is mostly automated by bots (if the package is hosted on GitHub or GitLab), but occasionally you need to debug a broken build. Some packages are hosted elsewhere (SourceForge, custom GitLab, Bitbucket, …) and updates are not automatically found. There is a great community around conda-forge, very detailed documentation and of course co-maintainers who can help you in case of questions.

If you are interested in helping out with any of the packages listed here, let me know.

3 Likes

Hi @awvwgk I would be glad to help with findent, I made the PyPi port using GitHub Actions, a while back so that Modern Fortran in VS Code could download it automatically. I could also help with ford and fprettify but I suspect these are handled pretty well by the conda-forge feedstocks.

As for the rest of the packages, I am more than happy to help keep the feedstocks updated, but realistically I might not be have enough time for maintenance work.


Specifically for findent, if you are having troubles with sourceforge, I would try and get Willem Vermin, the author of findent involved to bring the github repo into a more conda-forge friendly state, e.g. remove jfindent and potentially switch to cmake. (Although I do think that findent’s use of automake/autoconf is pretty well made).

1 Like