Skip to main content

2020-05-27 conda-forge core meeting



Your agenda items

  • (all) intros for new people on the line?

    • Marcelo!
  • (CJ) standing budget item

  • (CJ) institutional partners metadata (

  • (ED) Should we just merge in the cfep PRs with the status of "deferred" since there's zero action on any of them?

  • (MRB) change how we mark packages as broken

    • currently we move packages to broken and remove them from main
      • this means users cannot recreate old envs where a package was marked as broken
    • new system would leave packages on main (only add broken label) and then remove them via the removals section of the repo data patches
      • this is how defaults does it
    • do we need to announce this before switching? should we switch?
    • side effects are that this procedure leaves the repodata in weird states
      • the only source of truth is the one on the CDN (any other source is wrong)
      • packages can have different looking requirements between broken and main labels even on the CDN
    • matching defaults is probably more important than the things above
    • TODO:
      • document how users are supposed to interpret broken label
      • update how we, as core, are supposed to mark packages as broken
      • (ED) document strategies for reproducible environments using conda-forge
  • (CJ) I'd like to form a finance subteam, if you are interested in serving please let me know.

    • numfocus point of contact
    • responsible for letting core know where we stand financially
    • pending financial matters
    • acting as final approvers
  • (JJH) Should tk require freetype and X11?

    • Fonts will look nicer in TK applications
    • Introduces new requirements (and download/disk space) to Python
      • fontconfig: 300kb, freetype: 1mb
      • some additional packages needed as well
    • Recommendation is to create two variants, with and without "nice fonts"
  • (IF) Making a linux-anvil-ppc64le package and distributing cudatoolkit in the docker image

    • There's no defaults::cudatoolkit for ppc64le, but the docker image is still useful to have
    • Even though we can't redistribute defaults::cudatoolkit we are doing it via docker as we are caching it.
    • Notes:
      • Make it clear to users that this docker image doesn't have cudatoolkit and why it doesn't have cudatoolkit.
  • (WV) "standardization" of a next gen package format and other parts of the conda ecosystem

    • Make available specs public? E.g:
    • Some notes regarding a next version of the package spec are written down here:
      • this current spec doesn't support everything one needs for the current stack
    • also some discussion on gitter and at bot subteam meeting a few months ago
      • using python as the language came up more than once
        • objections are that it is not static metadata and might be too hard to parse
      • deprecate selectors in favor of ...
        • jinja2 if statements (hard to parse)
        • letting any value in the config be a dict with the selector info in the key
          • this follows what rust does in their TOML
          • very easy to parse
          • always results in valid YAML
      • deprecate the use of some jinja2 elements (any control flow elements) since they are hard to parse
    • related to the conda working group that Kale is organizing
    • Interest
      • Jonathan Helmus
      • Wolf
      • Marcel
      • Scopatz
        • specifically interested in the activation scripts
      • Cheng?
      • Matt B.
      • Marcelo
      • Mike S.
      • John
  • (UK) static libraries in conda-forge

    • Our toolstack and systems are tailored for dynamic linkage, thus we want to focus on that in conda-forge
    • Users are interested in static libraries for some use cases, e.g.
      • Building wheels for PyPI on Windows
      • (MRB) Do we want to make a better effort to support this? Marking static packages and doing small migrations when we move compilers as needed? Our answer has been no. (UK: Note that the reported breakages were because of LTO- enabled static libraries, that's a next level)
      • static libraries can have compatibility concerns with compilers and ld/binutils
    • Go and Rust are separate discussions (packaging and licensing, etc.)
    • What do we do about accidental leakage?
      • remove them or mandate a split package
    • Add linting hints to builds to find them
    • Recommend how to package them
    • We should write docs saying we don't provide support and this is a bad idea.

Active votes

Subteam updates


Stuff from last week that we didnt get to








  • (ED) Any other updates on this one? Need any help?
    • (MRB) CFEP-13 is done.
      • Isuru suggested using the github api and that worked. Thanks!
      • All feedstocks converted over and staged-recipes is making new feedstocks with the right keys/tokens.
      • To move forward, we simply have to deactivate the binstar token and put a new one on heroku.
      • I will make an announcement and give people a few weeks.
      • We probably want to solve the rerendering issues with github first.
  • (MRB) next up is better user management

CI infrastructure

Compiler upgrade

CFEP updates

Open PRs

  • cfep-04 X11 and CDT policy

    • INACTIVE - Merge in with some inactive-esque status?
    • Needs new champion. Thanks for your work on this pkgw! Has unaddressed comments from pkgw as from Jan 10, 2020
  • cfep-06 Staged-recipes review lifecycle

    • INACTIVE - Merge in with some inactive-esque status?
    • Lingering comment from @saraedum. @jakirkham, can you reply? Has unadressed comment from @saraedum from Jan 8, 2020
    • (MRB) The stalebot has solved the worst of the issues here. I think we could defer this one permanently.
  • cfep-10 Feedstock statuses, unmaintained

    • INACTIVE - Merge in with some inactive-esque status?
    • Needs another review. Has unaddressed updates from pkgw as of Jan 11, 2020
  • cfep-12 Removing packages that violate the terms of the source package

    • Active debate about moving to "broken" vs deleting from conda-forge channel
    • Active vote, ends on 2020-03-11
    • What were the results of the vote?
    • Did we hear back from NumFOCUS?


Check in on previous action items

Copy previous action items from last meeting agenda.

Last meeting

  • (ED) Who we are page? Some combination of a FAQ and a who is everyone. FAQ things like:
    • who's the POC for CF <> Anaconda, CF <> NumFocus, CF <> Azure
    • who's the POC for the various subteams?
    • Informal information: roles, day jobs, bios, the whole nine yards, why you're here, etc.
    • Public or internal? I don't really care either way. Anyone feel strongly one way or the other?
    • opt-in to public bios
    • software carpentry has a large number of instructors and has
    • some concern about "yet another place to keep stuff up to date"

3 meetings ago

  • (Kale) schedule conda working group
  • (CJ) Institutional Partners page in docs
    • TODO: Submit skeleton for PR into repo

Move to Issue Tracker

  • cfep-10 next steps: CJ to call a vote for feedback
  • cfep-06 next steps: Ask staged recipes team to champion this CFEP and move it forward
  • jakirkham & CJ-wright to sync on adding CUDA to the migration bot
  • (Eric) Scheduling Anaconda <-> conda-forge sync on requirements gathering
    • Will try and get this scheduled in the next month.
  • (Anthony) Reach out to NumFocus to figure out legal ramifications of not including licenses in files.
  • (Eric) check internally for funding levels for hotels & flying folks from the community in?
  • (Eric) Figure out finances of conda-forge to support themselves?
  • (jjhelmus) Open up CFEP for which python's we're going to support
  • Remove conda forge readthedocs.
    • done already
  • (jakirkham) write a blog post on CUDA stuff we discussed today
  • (jakirkham) update docs on how to add CUDA support to feedstocks
  • (jakirkham) will open an issue on conda-smithy to investigate Drone issues. (ping the aarch team)