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

How are build systems supposed to choose configurations of transitive dependencies?

Open
  • Is something wrong?
#27 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Documentation
Clarity
Needs clarification
Activity status
Stale
Domain
build-system

Research direction

Start by reading the CPS specification sections covering components, Requires, and configurations, then review the nine comments for any emerging consensus. Compare the three approaches described in the issue and document clear guidance for build tools and packagers, including whether the approaches can coexist.

Written by the indexing model from the issue text.

Description

Say we have:

  • A package A with a component A. A:A has a Requires on B:B.
  • A package B with a component B. B:B has two configurations, B-config1 and B-config2.

And now say that the user of a CPS-compatible build tool wants to build their project against A:A. The build tool will have to transitively process B:B, and will have to choose whether it consumes the B-config1 configuration or the B-config2 one. How do you envision that tools should do this? I can think of three different approaches:

  • The user of the build tool explicitly specifies the desired configurations even for their transitive dependencies. So the user, somewhere in their build config, would have to specify "For B:B, I want to use B-config1". This is not very scalable, specially as dependency trees become deeper and deeper. For deep dependency trees, the user might not even know about B, so they wouldn't necessarily be capable of choosing between config1 and config2.
  • Requires in components should explicitly specify their desired configs. A:A, instead of Requiresing B:B, would explicitly require B:B@B-config1 (which is already permitted by the specification). This is an expectation we would be placing on packagers.
  • Packages only define configurations with semantics that are well known to the build tool. When the build tool finds B-config1, it doesn't know what B-config1 means, so it cannot choose for the user. However, if the configurations were just static and shared, the build tool could choose itself to use static if the user expressed a preference for static linking. Build tools could support other well-known configuration names, and packages and components would be created that provide only such well-known configurations. This would imply a contract between package manager/packagers/build tools about what configuration names have well-known semantics (like static, shared, ...)

The specification doesn't necessarily have to prescribe one of these three options. The current version allows for the three, and it would be a matter of how the ecosystem grows around it. Perhaps the three can coexist for different use-cases.

But maybe you already have something in mind, and it could be useful to provide guidance in the site.

Dominant language
Python
Stars
191
Forks
14
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.