Project name
sig-purls
Existing repository URL
No response
Project description
PURLs as identifiers
conda packaging artifacts as exposed in repodata lack unique identifiers, formally. Informally, the community has relied on their download URLs (e.g. see rattler lockfiles or @explicit files in conda), but these do not necessarily tie an artifact to the record metadata exposed in the repodata.json file (especially not when base_url and the upcoming url fields are used). Since the same artifact can be exposed in different repodatas with different (patched) index metadata, download URLs are no longer unambiguous.
PURLs (Package URLs) seem like a good choice to rely on, but their current standard is insufficient to capture the nuance of the conda ecosystem in its multi-stakeholder era. CEP PR #159 proposes a series of adjustments to modify the PURL standard.
PURLs as connectors to upstream
conda packaging is often use to redistribute existing software published elsewhere (e.g. from PyPI or Github repositories). We are not annotating this relationship explicitly, and especially not in an easy way to consume or discover systematically. There are two overlapping CEP drafts that propose to add these relationships to upstream as PURLs in the recipe (#63 and #114, that need resolution. Some pending questions are:
- What's being annotated? Sources only? Also vendored? Are we categorising them?
- Are these fields part of repodata? Should they? Which ones if more than one?
But providing a metadata slot is only the first step. There are pending challenges about how to populate the existing packages retroactively and confidently, probably not dissimilar to the exercise of mapping conda packages to their upstream source without PURLs.
Mappings for interoperability and security coordination
Once we have PURLs identifying both the conda artifacts and their upstream sources, we enable a few things that had been challenging so far:
- Solve packages across ecosystems effectively. Mappings allow us to interface with other packaging ecosystems in an integrated way (e.g.
pypi-dependencies in Pixi could be co-solved, or conda-pypi indexing could have aliases to the conda counterparts).
- Provide metadata for other ecosystems. For Python packaging, these are behind PEP 725 and PEP 804. It would also enable us to participate in Repology.org
- PURLs are very popular in SBOMs and vulnerability reports because they can identify software across ecosystems. Devising ways to expose and tie CVEs to conda packages may be beneficial and even required in the future.
- Special mention: https://github.com/prefix-dev/purl-associator and https://prefix-dev.github.io/purl-associator/index.html
Conclusion
We need PURLs for many different ongoing efforts. Let's work together with representation from all those angles to make sure all needs are covered.
@conda/steering-council, I'm hereby requesting the creation of a PURLs SIG (Special Interest Group) as an incubated project in conda-incubator, whose purpose is the discussion and elaboration of PURL-related standards in our ecosystem. Once these standards are accepted, implemented and widespread, the SIG will dissolve.
License
BSD-3-Clause
Initial team members
Additional context
This is the first SIG we are creating. There's no precedent so I'm improvising a bit, but I think there are a couple points I'd like to make explicit: SIGs are ephemeral and should dissolve once their goal has been achieved; they should be easy to recognize with the sig-* prefix in the repo and team names; they are more about supporting coordination than establishing authority.
References
- Collected references from community meetings:
- Collected references from issue trackers:
- CVEs:
- CEPs:
- Blog posts:
Project name
sig-purls
Existing repository URL
No response
Project description
PURLs as identifiers
conda packaging artifacts as exposed in repodata lack unique identifiers, formally. Informally, the community has relied on their download URLs (e.g. see rattler lockfiles or
@explicitfiles in conda), but these do not necessarily tie an artifact to the record metadata exposed in the repodata.json file (especially not whenbase_urland the upcomingurlfields are used). Since the same artifact can be exposed in different repodatas with different (patched) index metadata, download URLs are no longer unambiguous.PURLs (Package URLs) seem like a good choice to rely on, but their current standard is insufficient to capture the nuance of the conda ecosystem in its multi-stakeholder era. CEP PR #159 proposes a series of adjustments to modify the PURL standard.
PURLs as connectors to upstream
conda packaging is often use to redistribute existing software published elsewhere (e.g. from PyPI or Github repositories). We are not annotating this relationship explicitly, and especially not in an easy way to consume or discover systematically. There are two overlapping CEP drafts that propose to add these relationships to upstream as PURLs in the recipe (#63 and #114, that need resolution. Some pending questions are:
But providing a metadata slot is only the first step. There are pending challenges about how to populate the existing packages retroactively and confidently, probably not dissimilar to the exercise of mapping conda packages to their upstream source without PURLs.
Mappings for interoperability and security coordination
Once we have PURLs identifying both the conda artifacts and their upstream sources, we enable a few things that had been challenging so far:
pypi-dependenciesin Pixi could be co-solved, orconda-pypiindexing could have aliases to the conda counterparts).Conclusion
We need PURLs for many different ongoing efforts. Let's work together with representation from all those angles to make sure all needs are covered.
@conda/steering-council, I'm hereby requesting the creation of a PURLs SIG (Special Interest Group) as an incubated project in conda-incubator, whose purpose is the discussion and elaboration of PURL-related standards in our ecosystem. Once these standards are accepted, implemented and widespread, the SIG will dissolve.
License
BSD-3-Clause
Initial team members
Additional context
This is the first SIG we are creating. There's no precedent so I'm improvising a bit, but I think there are a couple points I'd like to make explicit: SIGs are ephemeral and should dissolve once their goal has been achieved; they should be easy to recognize with the
sig-*prefix in the repo and team names; they are more about supporting coordination than establishing authority.References
governance/meetings/archive/20260422-conda-ecosystem.md
Lines 50 to 62 in f0d677b
governance/meetings/archive/20260429-conda-ecosystem.md
Lines 50 to 53 in f0d677b
PackageRecordceps#63