conda-forge anaconda.org requirements

The intent of this document is to capture things that the conda-forge team needs out of an anaconda.org replacement. There are a lot of features on anaconda.org. It would be really valuable for the Anaconda Product Management (PM) team (and the Engineering team) if we could get a sense of which features of the current anaconda.org the conda-forge team makes use of.Additionally, it would be valuable to understand where anaconda.org does not meet the needs of the conda-forge team. The combination of these two things (existing useful features and features you need) should provide us with guidance on what it is we should focus on in the near-term.

Current Anaconda.org features that are useful

Instructions: Please put your name in parantheses at the beginning of your note so we know who can speak in more detail. I'll seed this section with an example of what I'm looking for. Please feel free to add top-level feature descriptions!

• Labels on packages
  • (Eric) very useful because it allows us to leave packages up for reproducibility reasons while simultaneously preventing new installations of them in the case of the package is slightly broken, or we have migrated the compiler stack. The ask here is to continue having labels, or help us come up with a replacement option that serves our needs.
  • (Kale) The current implementation of the new repo doesn't have "labels" per se. The target is to be even more flexible. Each user or org has a "root" channel just as exists now, and then each user/org can have "subchannels", which are just like any other channel, but branch off the root. So you can still have the "conda-forge/label/gcc7" channel. No issues there. But you can also equally have "conda-forge/foo" as a channel if you really want. Really all we're doing is dropping the rigidness imposed by labels. I called it a "subchannel" only because random users can't arbitrarily create a "conda-forge/foo" channel; only admins for the root conda-forge channel can do that. Otherwise, subchannels behave just like any other channel. You will be able to easily move and copy packages between channels, so long as you have the necessary read and write access. That's slightly different than applying a label, but the effect is equivalent. We will probably put a limit on the number of levels (i.e. number of forward slashes) allowed in a channel name to avoid absurdity. The limit will be at least three levels–the root and two levels beyond–so two slashes within the channel name.
  • (Kale) Furthermore, with the new repo, deleting (or moving) a package doesn't actually mean deleting a package. If you took the https://conda.anaconda.org/conda-forge/osx-64/graphviz-2.38.0-he50ebb2_1009.tar.bz2 package and moved it to https://conda.anaconda.org/conda-forge/label/gcc7/osx-64/graphviz-2.38.0-he50ebb2_1009.tar.bz2, it would of course no longer be available at the original URL, but it would be available at https://conda.anaconda.org/conda-forge/osx-64/graphviz-2.38.0-he50ebb2_1009.tar.bz2?sha256=78b19151d8898893667481430f9f81ac7e11b49aa84239003b13510d73c8dbe0.
  • (Bjoern) metrices, like download statistics. This is important for funding agencies and therfore for a few community projects.
    • (Scopatz) I think that some of these are available if you know where to look and are willing to do the analysis - neither of which I know!

Desired features in Anaconda.org replacement

Instructions: Please put your name in parantheses at the beginning of your note so we know who can speak in more detail. I'll seed this section with an example of what I'm looking for. Please feel free to add top-level feature descriptions!

• Fine-grained package ACLs

  • (Eric) The conda-forge model makes heavy use of volunteer maintainers. These maintainers have complete control over how a conda package is built in the feedstock. Once their package makes its way to anaconda.org, they lose control over it and need a member of the core team to remove it, if a bad build leaks onto anaconda.org (This happens all the time). The ask here is to allow for per-package admin rights on a channel. (Isuru - not giving permissions to maintainers is okay in my opinion to make sure that maintainers don't remove packages without reason)
  • (Isuru) Maintainers have access to the anaconda.org token indirectly because that's needed in CI to upload and a maintainer can echo it in the CI script to get it. This is a security issue because a maitainer can gain access to the full anaconda.org site
  • (Kale) We intend to have ACLs that are confinable at least to the "common name" of the artifact. We'll be supporting more than just Conda packages (anaconda.org already supports Python and R packages), so if you're whitelisted for write access to "numpy", it might be the case that you get write access to any artifact where the common name is "numpy". If we add an extra degree of freedom to be able to restrict to artifact type, I become concerned about user-facing complexity.
  • (Kale) The design of the new repo is heavily "append-only," as I illustrated in my example above with being able to access an artifact even after it's been moved or removed. Users with write access to an artifact can always go back and undo.

• Uploading source tarballs

  • (Isuru) It'll be great to have a way to upload source artifacts, so that they are preserved. (conda-build can be changed to look in anaconda.org in addition to the original URL)

• Exposing more/flexible informations about a pkg

  • (Bjoern) e.g. maintainers, crosslinks to other sites, Document Object Identifiers (DOIs), Links to Containers etc.

• Artifact inspection

  • (Scopatz) What I often need is the ability to know which package a file comes from - usually a CLI or lib. Right now, I do this by going into pkgs/ and searching, which kinda sucks.
  • (Kale) Check out conda package --which. I think that's close to what you want – within an existing environment. Also at some point the view for an individual package file on anaconda.org definitely needs to show the paths that the package contains. A good example of this done well is https://centos.pkgs.org/7/epel-x86_64/nginx-1.12.2-3.el7.x86_64.rpm.html.
  • (Scopatz) Yeah, that solves part of this problem. I'd also generally like the ability to search for an *.so or similar so that I kno which package to install (ie that file isn't yet in any environment)

• Dark mode

  • (Scopatz) I know it is a stupid UI thing, but a dark mode for the website would be amazing!