feat: add stage-slices key

[mr-cal]

• Have you followed the guidelines for contributing?
• Have you signed the CLA?
• Have you successfully run make lint && make test?https://docs.google.com/document/d/1tQUv6iMq06uq5-dMPAX0qnOr0Qx0NASA7aceuoZUc-I/edit?tab=t.0
• Have you added an entry to the changelog (docs/reference/changelog.rst)?

---

Adds a stage-slices key per ST179.

Split into 3 commits for your reviewing pleasure.

This is how I understood the division of responsibility between craft-parts and craft-application/downstream apps:

craft-parts

• All validation and errors related to defining slices in stage-packages and stage-slices.

craft-application

• Deprecation warnings about using slices in stage-packages.
• Deciding when to allow slices in stage-packages.

(CRAFT-5253)

[Copilot]

Pull request overview

This PR introduces first-class support for declaring Chisel slices via a new stage-slices key, while keeping (deprecated) slice support in stage-packages behind an opt-in/opt-out flag for downstream applications.

Changes:

• Add stage-slices to PartSpec, including mutual exclusivity with stage-packages, and propagate stage_packages_slice_support through LifecycleManager/ProjectInfo.
• Add a dedicated ChiselSliceStr constraint (regex + custom error message) and test coverage for slice naming rules.
• Update package handling and executor plumbing so stage-slices behaves like stage-packages for fetch/unpack and triggers adding chisel as a build snap when needed.

Reviewed changes

Copilot reviewed 17 out of 17 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
craft_parts/parts.py	Adds stage_slices, mutual exclusion with stage_packages, and context-based validation for deprecated slices in stage-packages.
craft_parts/constraints.py	Introduces ChiselSliceStr and shared regex-validator utility with a custom error message.
craft_parts/utils/deb_utils.py	Adds helpers to detect slices/packages and reuses them across deb/chisel handling.
craft_parts/packages/deb.py	Switches slice detection to shared deb_utils.has_slices and removes the local helper.
craft_parts/executor/part_handler.py	Treats stage-packages and stage-slices identically when fetching stage content.
craft_parts/lifecycle_manager.py	Threads stage_packages_slice_support to part building and ensures chisel snap is added when slices are present.
craft_parts/infos.py	Persists stage_packages_slice_support on ProjectInfo for consumers.
craft_parts/state_manager/pull_state.py	Tracks stage-slices in pull-state properties of interest.
tests/unit/test_parts.py	Expands spec unmarshal/marshal and validation tests for stage-slices and stage_packages_slice_support.
tests/unit/test_lifecycle_manager.py	Adds tests for ProjectInfo.stage_packages_slice_support and stage-slices triggering chisel.
tests/unit/test_constraints.py	New unit tests for ChiselSliceStr naming constraints and error messaging.
tests/unit/packages/test_chisel.py	Updates tests to use deb_utils.has_slices instead of the removed deb helper.
tests/unit/executor/test_part_handler.py	Tests identical handling of stage-packages vs stage-slices by the part handler.
tests/unit/features/overlay/test_parts.py	Updates overlay marshal/unmarshal expectations to include stage-slices.
tests/conftest.py	Adds an is_deb_based fixture to standardize deb-platform mocking.
docs/reference/changelog.rst	Documents the new stage-slices key and the stage_packages_slice_support parameter.
docs/common/craft-parts/reference/part_properties.rst	Adds stage_slices to the published part properties reference.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[mr-cal]

This refactoring wasn't strictly necessary, but the duplication was bothering me and it made the validator more readable.

Plus craft-application will be able to leverage these for deprecation warnings.

[mr-cal]

This is a verbatim copy from craft-application.

[cmatsuoka]

We originally had debs or slices in stage packages, and the installation logic invoked _unpack_stage_packages/_unpack_stage_slices for each of the cases based on the contents of stage_packages. Now that we have specialized stage slices (which can be deb or other types of slices), it looks like we could move this decision one level up and invoke unpack_stage_packages/unpack_stage_slices from there instead of conflating everything into stage packages, and have two clean, separate paths for each format, wdyt?

[mr-cal]

I'm not sure if that would gain us much. Since we still support slices in stage-packages, we still need to keep the logic that de-conflate slices from a stage-packages entry.

If we had entirely removed that, then yes I think your refactoring idea would be a great idea.

I'm not opinionated on whether that logic lives in craft_parts.packages.Repository or craft_parts.executor.PartHandler, but I don't see a strong reason to move it in this PR.

[jahn-junior]

The updated key descriptions LGTM. Thanks!