Skip to content

Thread VcsEnvironment through _run_cmd and unify pyproject tool_names derivation #1425

Description

@RonnyPfannschmidt

Follow-up from #1424

The warning leak fix (#1424) consolidated VcsEnvironment threading through the public API layer. Two deeper cleanup tasks remain:

Phase 5: Fix standalone os.environ reads in _run_cmd and _scm_version

  • _run_cmd.run() reads os.environ directly for timeout and subprocess env
  • _scm_version.py reads SOURCE_DATE_EPOCH from os.environ as a fallback factory
  • These are low-level utilities called from every VCS backend, so threading env requires touching git/hg/jj backends

Phase 6: Unify pyproject tool_names derivation

  • pyproject_tool_names() on VcsEnvironment uses special-case mapping (VCS_VERSIONING -> vcs-versioning)
  • Tool names should be made properly configurable via an explicit mapping parameter on VcsEnvironment rather than guessing from env-var prefix casing conventions
  • This would also allow removing the tool_names parameter from Configuration.from_file and read_toml_overrides standalone function (legacy paths)

Both are internal cleanups with no user-visible behavior change beyond slightly better environment isolation in edge cases.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions