-
Notifications
You must be signed in to change notification settings - Fork 147
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
Abillity to split pixi.toml into multiple files #1285
Comments
Interesting. I really appreciate the possibility to keep all my env-related stuff in one file instead of having multiple environment.yml's like I did with conda before. Moreover, possibility of bundling Pixi into pyproject.yml is also nice for python-only projects. Would be interesting to see work on such a large project |
Yes, lovely stuff, and could potentially help reduce duplication in matrix use cases, and enable monorepos and skeleton-based tools to get spun up on As long as there is a way to get a single inspectable file back out, fully realized, things are pretty ok. Otherwise, behold the nightmare that is GitHub actions
Yep, TOML is quite resilient to #!/usr/bin/env bash
cat pixi.base.toml src/*/pixi.partial.toml > pixi.toml
set -eux
for task in "$@"; do
pixi run $task
done Writing those files can be a bit hard to reason about, however, as all those paths need to be
As with the Typographically, this could be adaptable here, assuming a reserved namespace delimiter, e.g. [project]
includes.docs = "docs/pixi.toml"
includes.atest = { manifest = "atest/pixi.toml", features = ["deps-atest"] }
[project.includes.ff]
manifest = "atest/pixi.toml"
features = ["tasks-atest"]
env = { BROWSER = "firefox" }
[project.includes.cr]
manifest = "atest/pixi.toml"
features = ["tasks-atest"]
env = { BROWSER="chromium" }
[tasks.all]
depends_on = ["docs:build", "ff:robot", "cr:robot"]
inputs = [
"build/docs/.buildinfo",
"build/reports/robot/chromium",
"build/reports/robot/firefox",
]
[environments]
docs = ["docs:deps-docs", "docs:tasks-docs"]
atest = ["atest:deps-atest", "ff:tasks-atest", "cr:tasks-atest"] Dangerously close to going down the spaghetti route of "post-install hooks": if an [project.includes.ex]
manifest = { environment = "default", path = "share/pixi/tasks/example.com/pixi.toml" }
env = { EX_PROJECT_NAME="my-project" }
[feature.baseline.dependencies]
example-com-pixi-tasks = "2024.04.*" Having been down this road, it gets pretty hairy if a child wants to reference its parent files, features, tasks, etc. This could either be banned (which would limit the overall functionality) or would require some more syntax to make an includable partial contract more explicit and self-documenting, e.g. [partial]
parent = "root"
# just use JSON Schema: don't get fancy
[partial.env.EX_PROJECT_REPO]
description = "the location of repo"
[partial.env.EX_PROJECT_NAME]
description = "a lovely project name according to your friendly example.com company policies"
pattern = "[a-z][a-z/d\\-]+" |
Looking at Rerun's Since the pixi project started we've thought about a "Workspace" feature. Which would allow you to have multiple manifest files which can be included in the main manifest file. Taken huge inspiration from https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html and https://docs.npmjs.com/cli/v7/using-npm/workspaces Quick summary on the workspace feature:
I know we're being credited for not splitting our configuration into multiple files which is something I take seriously as well. |
With a SAT hammer sitting around, it's nice if everything is a package nail, but needing |
Yeah, workspaces very much sounds like a direction that would work well for us. This one definitely isn't urgent at all but came up when I was talking to Tim and Bas last week so I opened an issue to keep from forgetting about the idea. |
I would personally not be in favor of making a split manifest functionality without additional features(like workspaces) that can benefit from this as it would add additional complexity to both the pixi code base and when misusing this, also to the projects them self. |
Problem description
We have a large, and growing pixi.toml file
It has grown to the point where some kind of hierarchical file-based organization would be helpful.
There are clearly different ways to partition: by function such as task vs dependency, by environment, by project sub-directory, including dependencies and tasks related to a given part of the code-base.
However, at a minimum just a way to include other files so create a pixi.toml that is a concatenation of all the included files might help bring a little bit of organization to things.
The text was updated successfully, but these errors were encountered: