Define and document [package] property inheritance from [workspace]

[Hofer-Julian]

In this simple example, both workspace and package are defined in two separate same manifest.

# /first/pixi.toml
[workspace] 
channels = ["https://prefix.dev/conda-forge"]
platforms = ["win-64", "linux-64", "osx-arm64", "osx-64"]
preview = ["pixi-build"]

[dependencies] 
rich_example = { path = "package/pixi.toml" }

# /first/package/pixi.toml
[package] 
name = "rich_example"
version = "0.1.0"

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

The package is added to the workspace as path dependency, and package.channels is inherited from workspace.channels.
Unlike with Cargo, inheritance isn't opt-in with something like channels = { workspace = true }.

Things get a bit more complicated when depending on a package that is already part of a workspace.
Cargo solves that by depending on the top-level manifest, rather than the manifest of the package.
In our case, this would look like this:

# /second/pixi.toml
[workspace] 
channels = ["https://prefix.dev/conda-forge"]
platforms = ["win-64", "linux-64", "osx-arm64", "osx-64"]
preview = ["pixi-build"]

[dependencies] 
rich_example = { path = "/first/pixi.toml" }

Open questions

• Should we allow [workspace] in package manifests that are already part of a workspace? I could imagine that could cause a bit of confusion.
• Source dependencies can also be added to feature dependencies. Should we allow the following?

# /first/pixi.toml
[feature.build.dependencies] 
rich_example = { path = "package/pixi.toml" }

# /second/pixi.toml
[dependencies] 
rich_example = { path = "/first/pixi.toml",  feature="build" }

[baszalmstra]

Source dependencies can also be added to feature dependencies. Should we allow the following

Features are not a thing for packages at the moment. So the above example would not work.

Should we allow [workspace] in package manifests that are already part of a workspace? I could imagine that could cause a bit of confusion.

In cargo you can define a workspace in a package as well. This excludes it from the "top-level" workspace.

We could also consider using members in the workspace definition to be more explicit which packages are part of the workspace and which are not. This is more similar to uv and cargo.