conda-forge core meeting 2023-09-20¶
Add new agenda items under the Your __new__() agenda items
heading
Attendees¶
Name |
Initials |
GitHub ID |
Affiliation |
---|---|---|---|
Daniel Ching |
DJC |
carterbox |
Argonne National Laboratory |
Jaime Rodríguez-Guerra |
JRG |
jaimergp |
Quansight/cf |
Sylvain Corlay |
SC |
SylvainCorlay |
QuantStack |
Thorsten Beier |
TB |
derThorsten |
QuantStack |
Katherine Kinnaman |
KK |
kathatherine |
Anaconda |
Wolf Vollprecht |
WV |
wolfv |
|
Matthew R Becker |
MRB |
beckermr |
cf |
Jannis Leidel |
JL |
jezdez |
Anaconda/cf |
X people total
Standing items¶
[ ]
From previous meeting(s)¶
[x] (HV)
-dev
vs.-devel
came up in boost unification, current PR uses the latter based on Isuru’s rationale
matches Anaconda naming & CDTs, does not match recent CUDA feedstocks, tangentially related to distro discussion (RHEL vs. Debian). We should try to choose one.
JRG: Our own data
[x] (HV) Branch deletion policy?
I’d suggest to delete dead branches on feedstocks (e.g. long-EOL maintenance branches), and keep history as a git tag on the feedstock. Thoughts?
MRB: Historic norm is to leave this to feedstock maintainers.
JRG: if we go this way, make it happen via admin-requests, not through UI with no papertrail (automation for the win!)
Active votes¶
[ ]
Your __new__()
agenda items¶
[x] (HV) Yearly python releases vs. 5 year upstream support
Releases moved closer together due to PEP602, 3.8 still has one full year before its EOL when we start with 3.12 migration (details).
Generally: Do we prefer 5 CPython builds, or are we fine with dropping support for
v3.{N-4}
one year before its EOL?Jannis: Look at https://github.com/ContinuumIO/anaconda-package-data/issues/41 again
MRB: conclusion “we’ll make a best-effort committment to all 5 python versions but individual feedstock manitainers may remove older versions at their discretion.”
[x] (IF) MinGW with UCRT64 toolchain and updated M2
Binary repackage of MSYS2 packages (for build only. No linking with downstreams)
Binary repackage of
libgcc, libwinpthread
Getting rid of
m2w64-
packagesCan we use MSVC/VisualStudio built packages?
Are there any that we use with C++ dependencies?
Current use is limited to https://gist.github.com/isuruf/d24ebbfaf06318beb992349c90e61ca0
MSYS2 bug:
$(cygpath -w $(cygpath -u $CONDA_PREFIX/Library/bin)) = $CONDA_PREFIX/Library/usr/bin
Get more storage on anaconda.org/isuruf
Jannis: I’ll ask at Anaconda, how much do you need?
2GB
[X] (SC) Emscripten-wasm-32 builds on conda-forge
Presentation of emscripten-forge by Thorsten Beier
Presentation of use cases
Potential CFEP opening
Questions:
Use CMake directly instead of em-make (?)
Compiler ABI incompatibilities might make it hard to have global migrations.
Support needed at conda-index & anaconda.org: add issue in conda/infrastructure.
We should start an issue in conda-forge/conda-forge.github.io
Pushed to next meeting¶
[ ] (JK) NumPy 2.0 planning
https://github.com/conda-forge/conda-forge.github.io/issues/1997
https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/issues/516
HV: Should be possible to only build against 2.x, result will be ABI-compatible with 1.2x
IF: It will not be ABI compatible if the package author changes
NPY_TARGET_VERSION
. Need ways to ensure that it does not happen.
[ ] (JRG) Post-mortem on the Windows upload issue introduced in conda-smithy 3.26 (now fixed)
[ ] (JL) FYI the creation of a conda “build tools” team under conda governancy policy (still federated until team figures out team charter) for conda-build and hopefully other build tools, welcome to join:
[ ] https://github.com/conda/conda-build/issues/4698
CFEPs¶
[ ]