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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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