conda-forge core meeting 2023-11-29

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

• Zoom link
• What time is the meeting in my time zone
• Last week's meeting

Attendees

Name	Initials	GitHub ID	Affiliation
Daniel Ching	DJC	carterbox	Argonne National Lab
Bianca Henderson	BH	beeankha	Anaconda
Marcel Bargull	MB	mbargull	Bioconda/cf
Marcelo Trevisani	MDT	marcelotrevisani	conda-forge
Marius van Niekerk	MvN	mariusvniekerk	Voltron Data / cf
Cheng H. Lee	CHL	chenghlee	Anaconda/cf
John Kirkham	JK	jakirkham	cf/NVIDIA
Matthew R Becker	MRB	beckermr	cf
Dave Clements	DPC	tnabtaf	Anaconda
Wolf Vollprecht	WV	wolfv	prefix.dev

13 people total

Standing items

• [ ]

From previous meeting(s)

• (JK) Miniforge 23.10
  • https://github.com/conda-forge/miniforge/issues/511
  • 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
  • https://github.com/numpy/numpy/pull/24861#issuecomment-1776781838
  • Expect upstream numpy 2.0 release late 2023/early 2024, so we should be ready to handle this.
  • As a group, we should decide on what we want numpy to do and document that as a new numpy issue or comment the webpage repo issue ( https://github.com/conda-forge/conda-forge.github.io/issues/1997 ).
• (JRG) New conda-forge.org plan
  • https://github.com/conda-forge/conda-forge.github.io/issues/1971
  • Old red/orange + green color combination had accessibilty issues
  • Make sure we don't break (perma-)links when moving to new framework
  • Find another accent color away from red+black.
    • Folks are possibly fine with blues and greens too
    • Orange has some accessibility issues in general
    • Some palettes:
      • https://coolors.co/edf0da-f0dfad-8f2d56-ff6542-218380
      • https://coolors.co/1be7ff-6eeb83-e4ff1a-ff6542-e8aa14
  • Status page: progress bar should count "In PR" as Done
  • Some crosslinks deep in the documentation didn't work.
• (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
  • https://github.com/conda-forge/conda-forge.github.io/issues/1901
  • 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 🥳)

CFEPs

• [ ]