Skip to main content

conda-forge core meeting 2024-04-17

Add new agenda items under the Your __new__() agenda items heading


NameInitialsGitHub IDAffiliation
Marcel BargullMBmbargullBioconda/cf
Cheng H. LeeCHLchenghleeAnaconda/cf
Eric DillEDericdillanaconda/cf
Dasha GurovaDGdashagurovaanaconda/conda
Ralf GommersRGrgommersQuansight
Klaus ZimmermannKZzklausQuansight
John KirkhamJKjakirkhamNVIDIA/cf

X people total

Standing items

  • [ ]

From previous meeting(s)

  • [ ]

Active votes

  • [ ]

Your __new__() agenda items

  • (HV) Finish compiler doc update (open since a year)
    • I'm trying to document the status quo, Isuru says it's a policy change --> let's figure it out and make a choice together.
      • Text has been restructured to discuss ABI breaking and non-ABI breaking changes in different sections; there is no actual policy change.
      • (IF) In that case, we should be okay to merge.
    • I'm waiting for this to add docs for {{ stdlib("c") }} on top.
  • (HV) stdlib migration status
    • based on some crude github searches, we're at ~250 migrated feedstocks out of ~5000 that are using a compiler
    • Matthew suggested switching it on for the version migrator as well - I like this
      • There was areement that this is a good idea
    • Downside is the migrator will fail (reason) for recipes with templated output names (thankfully there are few of those, and even more rarely is it necessary)
    • What kind of percentage threshold do we want to achieve before bumping c_stdlib_version?
      • See below
    • Idea: despite being ABI-compatible, run an explicit compiler migration for GCC 13 / LLVM 17; that way, we catch all feedstocks using {{ compiler("c|cxx" }} with the piggyback.
      • Would cause high CI load, and ultimately we decided we don't need to have every feedstock stdlib-enabled before bumping the versions, as long as the piggyback keep working into the future (and the linter thing below)
    • (IF/HV) Create a linter warning to saying something like "please add {{ stdlib }} when using {{ compiler }}"
    • TODOs:
      • Stop adding c_stdlib{,_version} to always_keep_keys in conda-smithy
      • Update CI of staged recipes (still using boa, which limits conda-build to a too-old version)
  • (JK) NumPy 2
    • ABI compatibility
      • NumPy will build Python packages with the oldest support NumPy for that Python version. The thinking is it won't be possible to run with an older NumPy version.
      • Meaning the pin_compatible approach would go away
    • How do we upgrade?
      • When NumPy 2 comes out, most existing packages have a constraint to 1.x so. Maybe a handful need a repodata patch.
      • Could add migrator for NumPy 2
      • Piggyback migrator to remove pin_compatible (as there is an existing run_exports in NumPy already)
      • NumPy 2's run_exports would have 1.22 (this needs to be fixed; easy to do)
      • Would we want to start a migration using the NumPy 2 RC with a label (like what we did with Python 3.12)?
      • Tricky to know what packages support NumPy 2
        • Like Windows uses 64-bit ints now instead of 32-bit
      • Release timeline for NumPy 2
        • Chicken and egg: Projects need to adopt NumPy 2 to make it easier to release
        • Maybe mid-May
  • (JK) Python 3.8 + crypt issues
    • (MB) Not a bug in general. Compiler packages should include the right flags to find header files from sysroot; failures typically expose issues in other places.
    • (IF) In this case, upstream build system is not properly using already-existing CXXFLAGS. This is something that needs to be fixed in the upstream & Makefile.
  • (WV) CEPs for rattler-build - looking for comments, discussion
  • (WV) R on Windows - revive?
  • (NM) PRs for rattler-build support

Pushed to next meeting

  • (JK) GLIBC 2.28
  • (WV) Big Windows machine - next steps?
  • (FF) Conda-forge social media presence
  • (FF) NumFOCUS PoC and financial team members


  • [ ]