Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Proposal: Add `package_url` and `package_provider` to CPS supplemental schema

Aperta
  • Qualcosa non va?
#97 3 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Ambito
documentation

Direzione di ricerca

Nell’issue non è indicato alcun file o test; inizia individuando lo schema CPS Supplemental e rivedendo il contesto collegato di spdx-to-cps e CMake. Il lavoro è completato quando la decisione sullo schema è registrata per entrambe le proprietà opzionali del pacchetto, con la semantica dichiarata e degli esempi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement help wanted scheduled

Summary
Request to add two new CPS Supplemental properties: package_url and package_provider.

These supply provenance and discovery metadata that help consumers trace, reproduce, and report package origins.

This proposal grew out of spdx-to-cps, where we saw a need to represent provenance fields.

As noted in CMake issue #27128:

"Sbom generation would like to list all the information it can, including each dependencies Description, PackageUrl, Website, and License."

This proposal addresses the need for package_url (canonical retrievable source) as well as package_provider (ecosystem identifier).

Motivation / Problem
Currently, CPS packages contain metadata about the package name, version, and requirements, but lack a standardized way to indicate:

  • Where the package can be retrieved from (URL, registry, distribution archive, etc.).
  • Which provider or ecosystem is responsible for the package (e.g., vcpkg, Conan, system package manager).

This information is important for:

  • Reproducibility: tools or humans can trace back to the original distribution.
  • Provenance: consumers can validate where a package was sourced.
  • Ecosystem integration: enabling bridges between CPS and existing package ecosystems.

Proposed Specification Changes (Supplemental)

  1. package_url

    • Type: string

    • Applies To: package

    • Required: No

    • Semantics:
      A URL pointing to the canonical location of the package.
      This may be:

      • A fetchable VCS or distribution URL, e.g.:
        git+https://github.com/madler/[email protected]
        https://example.com/foo-1.2.3.tar.gz,
      • A canonical identifier (e.g. purl spec).

      At present, the spdx-to-cps script emits git+https://... style URLs.

    • Example:

      {
  "package": {
    "name": "zlib",
    "version": "1.2.11",
    "package_url": "git+https://github.com/madler/[email protected]"
  }
}

    Distinction from website:

    package_url identifies a canonical retrievable source for the package (e.g., VCS URL, distribution archive, or purl), while website is informational and intended to point to a project or package homepage for human use.

  2. package_provider

    • Type: string

    • Applies To: package

    • Required: No

    • Semantics:
      The ecosystem or distribution source that supplied this package.
      Intended values may include vcpkg, conan, system, spack, etc.
      Tools can use this to customize resolution strategies or provenance reports.

    • Example:

      {
  "package": {
    "name": "zlib",
    "version": "1.2.11",
    "package_provider": "vcpkg"
  }
}

Compatibility

  • Additive change, backward compatible.
  • Existing consumers that do not recognize these properties may safely ignore them.
  • If accepted into the Supplemental Schema, tools MAY support them.
Lingua principale
Python
Stelle
191
Fork
14
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cps-org/cps

Tutte le issue di cps-org/cps

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.