---
tags: [meeting-notes]
title: '2024-04-17'
---
# conda-forge core meeting 2024-04-17

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

- [Zoom link](https://zoom.us/j/9138593505?pwd=SWh3dE1IK05LV01Qa0FJZ1ZpMzJLZz09)
- [What time is the meeting in my time zone](https://dateful.com/convert/utc?t=5pm)
- [Previous meetings](https://conda-forge.org/community/minutes/)

## Attendees

| Name | Initials | GitHub ID | Affiliation |
| ----------------------- | -------- | --------------- | --------------------------- |
| Marcel Bargull | MB | mbargull | Bioconda/cf |
| Cheng H. Lee | CHL | chenghlee | Anaconda/cf |
| Nichita Morcotilo | NM | nichmor | prefix.dev |
| Eric Dill | ED | ericdill | anaconda/cf |
| Dasha Gurova | DG | dashagurova | anaconda/conda |
| Ralf Gommers | RG | rgommers | Quansight |
| Klaus Zimmermann | KZ | zklaus | Quansight |
| John Kirkham | JK | jakirkham | NVIDIA/cf |
| | | | |

X people total

### Standing items

- [ ]

### From previous meeting(s)

- [ ]

### Active votes

- [ ]

### Your `__new__()` agenda items

- [x] (HV) Finish compiler doc [update](https://github.com/conda-forge/conda-forge.github.io/pull/1950) (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.
- [x] (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](https://github.com/conda-forge/librobometry-feedstock/pull/20#issuecomment-2041618340)) 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`?
- Handled through linter rules, see below
- Idea: despite being ABI-compatible, run an explicit compiler migration for [GCC 13 / LLVM 17](https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/4890); 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 }}`"
- Follow-ups:
- [Remove](https://github.com/conda-forge/conda-smithy/pull/1908) `c_stdlib{,_version}` from `always_keep_keys` in conda-smithy
- [Update CI](https://github.com/conda-forge/staged-recipes/pull/26084) of staged recipes (still using `boa`, which limits conda-build to a too-old version)
- Add piggyback to [version migrator](https://github.com/regro/cf-scripts/pull/2459)
- Add [linter hints](https://github.com/conda-forge/conda-smithy/pull/1909) for stdlib-related things
- [x] (JK) NumPy 2
- https://github.com/conda-forge/conda-forge.github.io/issues/1997
- 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
- [x] (JK) Python 3.8 + crypt issues
- https://github.com/conda-forge/scalene-feedstock/issues/41
- (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 `setup.py` & `Makefile`.
- [x] (WV) CEPs for rattler-build - looking for comments, discussion
- [Jinja functions](https://github.com/conda-incubator/ceps/pull/71)
- [OCI storage](https://github.com/conda-incubator/ceps/pull/70)
- [Recipe serialization](https://github.com/conda-incubator/ceps/pull/74)
- [x] (WV) R on Windows - revive?
- (MB) Only loosely related: R 4.4 is going to be released in a couple of weeks (so people will have to look at R again in any case)
- (IF) Needs major updates to MSYS2 (mostly done), UCRT64 (need gcc, binutils, sysroot)
- Related issues:
- https://github.com/conda-forge/r-base-feedstock/issues/248
- https://github.com/conda-forge/conda-forge.github.io/issues/1654
- https://github.com/conda-forge/conda-forge.github.io/issues/1044
- [x] (NM) PRs for rattler-build support
- [ ] Latest PR to [conda-forge-ci-setup-feedstock](https://github.com/conda-forge/conda-forge-ci-setup-feedstock/pull/316)

### 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

### CFEPs

- [ ]