Skip to main content

conda-forge core meeting 2023-11-29

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


NameInitialsGitHub IDAffiliation
Daniel ChingDJCcarterboxArgonne National Lab
Bianca HendersonBHbeeankhaAnaconda
Marcel BargullMBmbargullBioconda/cf
Marcelo TrevisaniMDTmarcelotrevisaniconda-forge
Marius van NiekerkMvNmariusvniekerkVoltron Data / cf
Cheng H. LeeCHLchenghleeAnaconda/cf
John KirkhamJKjakirkhamcf/NVIDIA
Matthew R BeckerMRBbeckermrcf
Dave ClementsDPCtnabtafAnaconda

13 people total

Standing items

  • [ ]

From previous meeting(s)

  • (JK) Miniforge 23.10
    • Blocked on conda-build, conda-libmamba-solver buggy interaction; conda 23.11 expected to fix the issue(s).
    • (JRG) If there's no user demand/rush, we should wait until conda releases in the next few days.
    • (JK) Punt till next core meeting
  • (JK) NumPy 2.0
  • (JRG) New plan
  • (HV) what to do with CDTs for Alma 8
    • Ideally, make checklist with CDTs, for checking whether we can switch each to conda packages.

    • What are the constraints/criteria we should consider/use when selecting which CDT packages to build vs repack?

      • Generally, avoid building packages that are "too close to the hardware"
      • Otherwise, build from source like we did for X11 packages.
      • Need to figure out what versions we want to build ("old enough" and/or matching Alma 8 ABI)
      • Which built-packages do we want to/can safely ignore run_exports for? (Essentially, host-only packages that aren't pulled in at run time.)
    • Not going to be a single-person task to generate the list. Will need input from multiple community members.

    • Will be a lot of work, so we should get started now.

Active votes

  • [ ]

Your __new__() agenda items

  • (JK) CUDA Docker images
    • Nvidia removing CentOS 8 images due to distro hitting EOL; only images will be UBI8, Rocky Linux.
    • Currently switched conda-forge to UBI8
    • "Only matters" for CUDA 11. In a few years, we should have transitioned to conda packages for CUDA and removed the need for Docker images.
  • (DJC) Policy for CUDA arch targets and pruning CUDA archs
    • Some packages are too big to build within the 6 hour CI limit while targeting many CUDA architectures
      • examples include libmagma, libtorch
    • Maintainers don't always know how CUDA real/virtual architectures work
    • Some projects don't have default target CUDA archs
    • The linked discussion is about which CUDA archs should be targeted when the upstream project does not have defaults and in what order to drop archs in order to complete builds within the 6 hours
    • Can we offer better guidance to (feedstock) maintainers about which CUDA archs to target?
    • Some solutions to the 6h+ build time
      • Split libtorch build Python extension from libtorch (not supported right now upstream; needs work, unclear how much, to be asked)
      • Use the upcoming GPU server to run the builds there (no time limit)
      • Having archspec detect CUDA archs would make some of these discussion moot and alleviate 6 hour limits
        • virtual packages make packages less portable
    • No policy for now; use private server for now; investigate helping pytorch split; look at cudarchspec package

Pushed to next meeting

  • (JK) Miniforge 23.10
  • (JK) CUDA 11.8
  • (JK) CUDA 12.x
  • (JK) Conda + libmamba
  • (JK) Public visibility of Alma images on Quay
  • (HV) Archive k* ecosystem (see last comment here, has five +1's from core)
    • dead as a doornail, constant headache for migrations
    • archiving is reversible, so let's finally bite that bullet?
    • Can leave instructions in feedstock README (or a pinned issue) if someone comes along who wants to revive; however unlikely that is...
  • (HV) Migration for error_overlinking: true?
    • already being set for new feedstocks in staged-recipes, should roll out to existing ones too (eventually).
    • would be a good opportunity to do {{ stdlib }}-related changes (e.g. remove implicit run-export to C/C++ stdlib --> must be specified in recipe, error_overlinking will find missing instances; if not necessary, package dependencies get slimmed by migration 🥳)


  • [ ]