Template gaps found adapting to a source-only Python repo (Financial-Modeling)

[ptr727]

Context

While adapting the template to ptr727/Financial-Modeling — a source-only, uv-managed Python repo that never publishes to PyPI — several template-level issues surfaced, some flagged by Copilot on the downstream PRs. Filing them here so the next Python repo doesn't hit the same friction.

Downstream refs: Financial-Modeling #10 (closed — verbatim CODESTYLE copy that misdescribed the repo), #11 (the repo-adapted fix), #12, #13.

1. .editorconfig "mirroring .gitattributes" comment is inaccurate

The [*] "Defaults" comment says the LF exceptions mirror .gitattributes ("* -text plus the same LF pins"), but the two pin sets are not identical: .editorconfig pins .github/workflows/*.{yml,yaml} (and the catalog snippet workflows) to LF, while .gitattributes does not — git stays passive on workflows; only .editorconfig + CI enforce them.

• Impact: Copilot flags this as a documentation inconsistency on downstream PRs; it can misdirect future EOL-governance edits.
• Suggested fix: reword to distinguish the pins actually shared with .gitattributes (*.sh, Dockerfiles, spec/validate.py) from the .editorconfig-only workflow-YAML pin (git passive, CI-enforced). Note: the template's own .editorconfig carries this wording, so it propagates verbatim.

2. No uv.lock LF pin → recurring CI churn for Python repos

Under the CRLF [*] default with editorconfig-checker enforcing EndOfLine, uv.lock — which uv regenerates with LF on all platforms — fails the check unless pinned. Neither .editorconfig nor .gitattributes pins it.

• Impact: every uv lock / uv sync that rewrites the lockfile reds CI until the file is manually reconverted to CRLF — a maintenance trap for any Python repo that adopts the CRLF-default governance.
• Suggested fix: pin uv.lock to LF in both files for Python repos (same rationale as the existing shebang/Dockerfile pins — a tool regenerates it with a fixed ending):
  • .editorconfig: [uv.lock] → end_of_line = lf
  • .gitattributes: uv.lock text eol=lf

3. No canonical Python VS Code tasks snippet; ad-hoc && chaining breaks on Windows PowerShell 5.1

The template ships a .NET catalog/snippets/configs/vscode-tasks.json (all type: process — correctly shell-agnostic), but no Python equivalent. Downstream Python repos have improvised type: shell tasks that chain with && (e.g. uv run ruff check && uv run ruff format --check && uv run mypy src). && is not supported by Windows PowerShell 5.1, which is still the default VS Code task shell on many Windows setups; only PowerShell 7+ / POSIX shells support it. Copilot flagged this downstream.

• Suggested fix: add a canonical Python tasks snippet that avoids the trap — either type: process per step (like the .NET snippet), or pin the Windows shell to pwsh:

  "windows": {
    "options": { "shell": { "executable": "pwsh", "args": ["-NoProfile", "-Command"] } }
  }

  (Also worth including the on-demand Docker Lint: * group and language-verify/test tasks, so the Python task set is a first-class snippet rather than copied ad hoc from an existing repo.)

4. CODESTYLE Python section verbatim-propagates template-specific claims (root cause of the #10/#11 churn)

When propagated verbatim, the Python section misdescribes a source-only / mypy-in-CI / PEP 621 repo. Claims that don't generalize:

• pyright-strict as the CI baseline — a repo may run mypy in CI with pyright editor-only (Pylance).

• [dependency-groups] — vs PEP 621 [project.optional-dependencies] (+ the uv sync --extra dev install note).

• _version.py + hatch-vcs + PyPI publishing / uv build — vs a source-only repo with a static version and no publish step.

• MD033 as the disabled markdownlint rule — repo-specific (this repo disables MD013 + MD060).

• .vscode/tasks.json as the clean-compile task home — a repo may consolidate editor settings/extensions into <Repo>.code-workspace.

• Impact: a verbatim copy is inaccurate and gets closed (Financial-Modeling Update readme and workspace #10); every downstream must hand-adapt.

• Suggested fix: either (a) have propagation adapt these fields to the target repo instead of cloning, or (b) mark the Python section's repo-specific defaults explicitly (conditional phrasing: "if your repo publishes to PyPI…", "if CI runs pyright strict…"). The Financial-Modeling CODESTYLE now opens with an ## Adaptation note enumerating exactly these divergences so a future re-sync is a mechanical diff — that pattern could be templated.

5. (minor) Clarify VS Code config placement

State explicitly that editor settings/extensions may live in either .vscode/*.json or the <Repo>.code-workspace, but tasks / launch / debug configs can only be external .vscode/*.json (they cannot live in the workspace file). This avoids confusion when a repo consolidates settings into the workspace file but still needs .vscode/tasks.json — and the CODESTYLE [vscode-tasks] link should point somewhere valid in that case.

6. (minor) WORKFLOW.md not propagated

WORKFLOW.md (feature → squash → develop → merge-commit → main, enforced by branch protection) is present in the template but was missing from Financial-Modeling. Worth confirming the propagation covers it — and that downstream README "Repository files" indexes get a row for it.