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

      • Can 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

  • [ ]