Skip to content

feat(cli): add py script type & Python interpreter resolution (#3278)#27

Closed
mnriem wants to merge 1 commit into
mainfrom
mnriem-feat-3278-py-script-type
Closed

feat(cli): add py script type & Python interpreter resolution (#3278)#27
mnriem wants to merge 1 commit into
mainfrom
mnriem-feat-3278-py-script-type

Conversation

@mnriem

@mnriem mnriem commented Jun 30, 2026

Copy link
Copy Markdown
Owner

Summary

Implements github#3278 — the foundation step toward unifying workflow scripts under a single Python implementation per command (github#3277). Adds a third script variant (py) alongside sh/ps.

Changes

  • New choice: Add "py": "Python" to SCRIPT_TYPE_CHOICES in _agent_config.py. All VALID_SCRIPT_TYPES consumers (the init workflow step, commands/init.py, and integrations/_helpers.py) derive from this mapping, so they accept py without further change.
  • process_template() (integrations/base.py): Confirmed the existing generic script_type logic extracts py: from frontmatter unchanged. When the script type is py, the {SCRIPT} expansion is now prefixed with a resolved Python interpreter so .py scripts run portably (notably on Windows, where .py files aren't directly executable).
  • Interpreter resolution: New IntegrationBase.resolve_python_interpreter() helper — prefers a project venv (.venv/bin/python or .venv/Scripts/python.exe), then python3, then python, falling back to python3. project_root is threaded through the process_template() callers so the venv preference works.
  • install_scripts(): Copied .py files are now marked executable (previously .sh-only).

Out of scope

Adding py: lines to the templates' scripts: frontmatter is tracked separately in github#3283. Until then, {SCRIPT} is left literal for py (existing graceful fallback when no matching frontmatter line exists).

Tests

Added positive and negative unit tests:

  • Interpreter resolution: prefers python3, falls back to python, falls back to python3 when nothing is found, prefers POSIX/Windows venv, ignores a missing venv.
  • process_template with py: prefixes interpreter + rewrites path; sh is not prefixed; venv is used when project_root is passed.
  • install_scripts: .py/.sh made executable, non-script file is not.
  • New choice present in SCRIPT_TYPE_CHOICES / VALID_SCRIPT_TYPES; unknown variant rejected.

Verification

  • specify init x --script py completes without error and records "script": "py".
  • Full suite: 3860 passed, 4 skipped. ruff check clean on changed files.

🤖 This PR was authored autonomously by GitHub Copilot (model: Claude Opus 4.8) on behalf of @mnriem.

…ub#3278)

Introduce a third script variant alongside `sh`/`ps` as the foundation
for unifying workflow scripts under a single Python implementation.

- Add `"py": "Python"` to `SCRIPT_TYPE_CHOICES`; `VALID_SCRIPT_TYPES`
  consumers (init workflow step, init command, _helpers) pick it up
  automatically since they derive from that mapping.
- Add `IntegrationBase.resolve_python_interpreter()` (project venv →
  `python3` → `python`, falling back to `python3`).
- Prefix the resolved interpreter when `process_template()` expands
  `{SCRIPT}` for the `py` script type so `.py` scripts run portably
  (notably on Windows); thread `project_root` through callers so venv
  preference works.
- Make `install_scripts()` mark copied `.py` files executable too.

Includes positive and negative unit tests for interpreter resolution,
`py` template processing, the new choice, and script installation.

Assisted-by: GitHub Copilot (model: Claude Opus 4.8, autonomous)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@mnriem mnriem closed this Jun 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant