Skip to content

migration: setup-to-pyproject output rough edges + v-prefix pin examples #52

Description

@thorwhalen

Found during the first repo-improvement rollout pilot (a real Old→stub migration). Code-level fixes that need golden/doctest updates, so filing rather than drive-by-fixing:

wads-migrate setup-to-pyproject output:

  1. Emits the deprecated [project.license] text = ... table — should emit the PEP 639 SPDX string (license = "Apache-2.0").
  2. Leaves project_name = "" in [tool.wads.ci] — should fill it with the package name (empty string risks a wrong --cov target).
  3. Writes testpaths = ["tests"] unconditionally — when the repo has no tests/ dir (doctest-only suites are common), it should point at the package dir so CI collects doctests instead of falling back to rootdir-wide collection (which can import docsrc/conf.py and other non-test files).

v-prefix in pin examples (i2mint tags are bare versions like 0.1.81; @v0.1.81 references a nonexistent ref):
4. wads/data/github_ci_uv_stub.yml comment: change \@master` to a wads tag (e.g. `@v0.1.81`)— golden-pinned inwads/tests/data/golden/python_lib/.github/workflows/ci.yml, so fixing requires regenerating goldens. 5. wads/migration.py: docstrings, doctests (pin='@v0.1.81'), and the ci-to-stubhint string — which also suggestsgh release list -R i2mint/wads, but wads publishes tags, not GitHub releases (gh api repos/i2mint/wads/tags` works).

The shipped skills already document workarounds (wads-migrate SKILL.md post-conversion review note; wads-ci-health pin pitfall) — this issue is about fixing the sources so the workarounds become unnecessary.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions