Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: parsing of build backend configuration #2624

Merged
merged 8 commits into from
Dec 3, 2024

Conversation

baszalmstra
Copy link
Contributor

Adds parsing of build backend configuration to the manifest.

Description

Backends sometimes require explicit configuration for parameters that cannot be derived from the source or the manifest. Examples of these are additional CMake arguments, whether to build a noarch package for python and potentially many more settings that are configurable in a rattler-build recipe.

Design

To facilitate this we want to allow people to configure the backends in their pixi.toml/pyproject.toml while retaining the following properties:

  1. The manifest must have a schema. This should include configuration for the backend.
  2. The backend is responsible for the semantics of the configuration. E.g. how to merge certain configuration values.
  3. The backend should not have to read the manifest file. Pixi should pass in any configuration values.

With these requirements we designed the following:

[build-system]
build-backend = { name = "pixi-build-python", version = "*" }

[build-backend.pixi-build-python]
noarch = false

Considerations and implementation

We add the build-backend section which has one key that should be equal to the name of the build backend. This allows us to write sub-schemas that match on that specific key.

We choose to add an additional section because we are afraid otherwise the key becomes very long. E.g. build-system.config.pixi-build-python.

Pixi reads the configuration verbatim and passes this over JSONRPC to the build backend. The immediate downside of this approach is that providing context-aware errors becomes much harder. This is because there is no direct mapping from the TOML config to the parameters passed in JSON. This PR does not provide any mechanism to facilitate this either.

@baszalmstra baszalmstra marked this pull request as ready for review December 3, 2024 08:32
@baszalmstra
Copy link
Contributor Author

Im still thinking about the issue that configuration in the backend cannot be related back to the original source anymore. Im think that we could also include the original span of each value in the configuration that is passed to the backend perhaps.

Copy link
Contributor

@nichmor nichmor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good!

@tdejager tdejager merged commit d4f0dd7 into prefix-dev:main Dec 3, 2024
23 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants