`python3` example in slice design approaches contradicts itself

[lczyk]

python3 is used as an example twice in "grouping by function", and it feels like the two uses contradict each other:

intro says:

[python3 slice definitions file] has a core slice providing a very minimal python3 runtime, but also a standard slice with the additional libraries on top of core.

but the body says:

A minimal slice that offers a stripped down installation, to the absolute essentials... Taking the above python3 example, this slice would only contain the necessary dependencies to run a trivial "Hello World" script, and not much more.

so the intro implies python3.core is the minimal-runtime tier (no separate minimal slice in the SDF), while the body re-uses the same python3 example to illustrate the actual minimal tier. reader cant tell whether python3.core corresponds to minimal or core in the canonical naming.

btw, current python3.yaml in ubuntu-26.04 does not have a minimal slice, so "taking the above python3 example, this slice would only contain..." references a slice that isnt in the SDF. worth rewording the body bullet as hypothetical?? -- "if python3 had a minimal slice, it would only contain...". unsure about this one since it's a moving target: what if we add a minimal slice to pytohn3 tomorrow? do we update the docs yet again? feels like an unnecessary and subtle coupling of the two, but on the other hand the docs should reflect reality.

btw, btw, how about explicitly stating the superset chain? something like "dev is a superset of standard, which is a superset of core, which is a superset of minimal" -- i.e. each tier has the previous one in its essential, so installing dev transitively pulls everything below. the page lists the four tiers but never says how they relate, so a reader is left to infer it from the prose (which only gestures at it via "on top of core" in the intro and "dev slice which is the standard slice, plus..." in the dev bullet).

would also be worth flagging that the chain is opt-in -- not every package needs all four tiers. slicers pick the subset that fits the package (e.g. a leaf utility might only ship bins + copyright; a runtime might ship core + standard and skip minimal/dev). otherwise readers may assume all four are mandatory.

links

• source:

  chisel-docs/docs/explanation/slice-design-approaches.md

  Lines 27 to 34 in 8e996e3

  	[`python3` slice definitions file](https://github.com/canonical/chisel-releases/blob/ubuntu-24.04/slices/python3.yaml)
  	has a `core` slice providing a very minimal `python3` runtime, but also a
  	`standard` slice with the additional libraries on top of `core`.
  	In this case, the most common is to create:
  	- A `minimal` slice that offers a stripped down installation, to the absolute essentials, to make the software
  	work. In most cases, such a minimal installation may only be useful if used as a base for another installation/
  	build, where the developer adds their own additional dependencies. Taking the above `python3` example, this slice

• live: https://documentation.ubuntu.com/chisel/latest/explanation/slice-design-approaches/#grouping-by-function
• python3 slice in 26.04: https://github.com/canonical/chisel-releases/blob/ubuntu-26.04/slices/python3.yaml