Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
#97 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Domain
documentation

Research direction

No file or test is named in the issue; start by locating the CPS Supplemental schema and reviewing the linked spdx-to-cps and CMake context. Done means the schema decision is recorded for both optional package properties with their stated semantics and examples.

Written by the indexing model from the issue text.

Description

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.
Dominant language
Python
Stars
191
Forks
14
PR merge metrics
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cps-org/cps

All issues in cps-org/cps

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.