conda
Draft another CEP for PURL annotation
Rehashing discussion in https://github.com/conda/ceps/pull/63, more focused on about rather than index.
One comment here is that in the context of the github conda support rollout and then deprecation, I think we discovered that the mappings between ecosystems, if constructed without oversight, are pathways for potential security issues. I wonder how that kind of consideration might effect the design of this CEP. Certainly for conda-forge, we'd need knobs to control that mapping so that people cannot point a numpy to some other conda-forge package besides numpy.
The design of repodata patches, while it has warts, might help us here. We could designate a specially named conda package that holds the authoritative set of PURLS for that channel. A given channel could upload that package if they choose to do so and that would be the source of truth.
One simple path forward is to add purls to the repodata, source it from about, and also support patching it. Then conda-forge can override everything as needed using its patching codes, but other channels have a builtin mechanism. This would result in duplication, so it we may want to treat it more like run exports.