Skip to main content

2020-12-01 Conda Community Meeting

Attendees

NameInitialsAffiliationUsername
Gonzalo Peña-CastellanosGPCQuansight@goanpeca
Megan YancyMCYAnaconda@myancy-anaconda
Marius van NiekerkMvNFlatiron Health@mariusvniekerk
Cheng LeeCHLAnaconda@chenghlee
Eric DillEDDTN@ericdill
Crystal SojaCASAnaconda@csoja
Christopher J "CJ" WrightCJLab49@cj-wright
Keith KrausKKNVIDIA@kkraus14
Filipe FernandesFFIOOSocefpaf
Michael GrantMGAnacondamcg1969
Connor MartinCJMAnaconda@cjmartian
Marcel BargullMBBioconda / conda-forge@mbargull
Wolf VollprechtWVQuantStack / mamba@wolfv
Matthew BeckerMRB--@beckermr
Marcelo Duarte TrevisaniMDTconda-forge@marcelotrevisani
Michael SarahanMCSRStudio@msarahan

Agenda

  • Welcome

Announcements

Standing Items

  • Anaconda: Organizational-level CLA
    • No current updates.

New Agenda Items

  • Rotating Meeting Facilitator

    • Call for volunteers
    • Who wants to go next?
  • Conda Triaging and Issue Tracking meeting took place.

    • Meeting: Kale, Marcel, Gonzalo, Cheng
    • Splitting responsibility by day: each person triages issues that come in that day
    • conda-triage
  • Given that pip install conda still "works" but obviously installs something wildly out of date and non functional should we yank the releases on pypi ? (@marius)

    • Existing blog posts refer to conda being pip installable
    • Possible solutions:
      • could pipx install conda with a standalone binary?
      • pip install conda forcibly fails with a link to miniconda installer?
      • Remove the packages but reserve the package name?
      • Very long term: cool but probably impractical due to major technical challenges
    • Short term fix: Anaconda will replace with newer stub package on PyPI.
      • Create a conda-stub repository that creates folder with an empty package.
      • Will not remove package (without annoucement) to avoid breaking existing users & workflows.
      • Issue: https://github.com/conda/conda/issues/10388
  • Where are the conda-standalone binaries these days?

  • (MRB) package copying and package metadata on anaconda.org

    • We are having an issue in conda-forge where when we copy packages from one user to another using the copy API endpoint, the metadata per package (doc_url, dev_url etc) displayed on anaconda.org is erased. We need this metadata for certain packages, especially cudatoolkit.
    • We need two fixes:
      • support for patch requests for the anaconda.org /package/{owner_login}/{package_name} API endpoint so that we can restore the metadata
      • fix the copy endpoint so it does not delete this metadata
    • These will let us fix the packages we have and make sure it doesn't happen for new packages.
    • issue: https://github.com/Anaconda-Platform/anaconda-client/issues/556
  • Audit (CJ)

  • Raises the question of how to handle optional dependencies and/or sub-packages?

    • Like RPM provides?
  • Additional test "keys" for conda-build (WV)

Outstanding Items From the Previous Meeting

  • N/A

Active Votes

Subteam Updates

Open PRs

  • N/A

Discussion

Action items

Last meeting points (2020-11-17)

  • Ways to address diversity inclusiveness issues
  • Availability of artifact verification features to other pieces of software (than conda):
    • SA: @Wolf, Please be aware that at first, we're offering the trust and signing data to paid folks, because... lights on. But I don't see why support for consuming that data shouldn't be handled in any package manager frontend talking to the repository. There's a project with the majority of the low-level code and a set of algorithms. The process of integrating that into conda (or other managers) is a delicate thing, so I'm hoping that the guidelines are helpful enough... but this will improve after conda integration.
    • Wolf: sure. with quetz we're working hard to support mirroring of conda-channels (specifically conda-forge), and this trust & verification is pretty integral for that so ... we might have to implement this anyways, and then it would probably make sense to do it in the same fashion as upstream
    • SA: that'd be good, yeah. We can talk about the TUF work underlying it at the least