Drop step-specific "base Click command" implementations

[happz]

They are not that different, each step class just used different step name, and that was it. Dropping the base_command method from Step-like classes, replacing them with a shared implementation.

Also, --how now prints allowed/known plugins as possible choices. I was editing the help text, and this felt like a natural change of the option.

Pull Request Checklist

• implement the feature

[LecrisUT]

LGTM, just 2 minor issues.

[thrix]

Code Review: Drop step-specific "base Click command" implementations

Reviewed against commit 3e49a3b.

Summary

Clean refactoring that consolidates 7 near-identical base_command() implementations (one per step plugin class) into a single shared implementation in BasePlugin. Removes ~220 lines of boilerplate. The shared version uses a new _step_class ClassVar backlink to derive the step name, and enhances --how to show available plugins as choices in the metavar.

Issues

1. Execute step gains PHASE_OPTIONS — functional change (medium)

The shared base_command() always applies @tmt.steps.PHASE_OPTIONS. However, the original execute step was the only step (out of 7) that did NOT use PHASE_OPTIONS. This means execute now gains --insert, --update, --update-missing, --allowed-how, --name, and --order CLI options it didn't have before. This contradicts the code | no functional change label. See inline comment.

2. Unrelated FileSystemPath/Package re-exports in tmt/steps/provision/__init__.py (minor)

These imports from tmt.package_managers are added as re-exports but nothing in the codebase imports them from tmt.steps.provision. Unrelated to the base_command refactoring. See inline comment.

Observations (no action needed)

• The --how help text is now generic (f'Use specified method for {step_name} phase.') instead of step-specific (e.g., 'Use specified method for environment preparation.'). Minor wording change.
• The --how metavar now lists available plugins (e.g., beaker|connect|container|local|virtual) instead of the generic METHOD. Nice improvement.
• Removal of # type: ignore[type-abstract] in plan.py is correct — base_command was the only remaining abstract method in these plugin base classes, making them non-abstract now.
• The module-level XPlugin._step_class = X assignments are well-documented and all 7 steps are covered.

Verdict

The refactoring is clean and correct. The main concern is issue #1 — the execute step gaining new CLI options should be acknowledged (and the no functional change label reconsidered) or handled explicitly.

Generated-by: Claude Code

[thrix]

The shared implementation always applies @tmt.steps.PHASE_OPTIONS. However, the original execute step was the only step (out of 7) that did not have PHASE_OPTIONS — it only had --how. This means execute now gains --insert, --update, --update-missing, --allowed-how, --name, and --order CLI options it didn't have before.

This may be intentional and desirable (no obvious reason execute should lack them), but it's a functional change worth acknowledging — the PR is labeled code | no functional change.

Generated-by: Claude Code

[thrix]

These FileSystemPath and Package re-exports are unrelated to the base_command refactoring — nothing currently imports them from tmt.steps.provision. Should this be in a separate commit or dropped?

Generated-by: Claude Code