Skip to content

Installer: support uv for git-filter-repo and distinguish adoption readiness from general readiness #595

Closed

Description

@brettheap

Problem

On Raven (Omarchy / Arch Linux), installing openRepoShape v1.0.1 succeeds and ends with “this machine is ready”, but adoption immediately needs a missing prerequisite: git-filter-repo.

The release installer detects an existing git-filter-repo, otherwise installs git-filter-repo==2.47.0 only when pipx is present. This machine has uv but not pipx, so the installer skips installation and prints a python3 -m pip install --user command. That fallback is not appropriate for an externally managed system Python such as Arch’s. The missing dependency does not affect the installer exit status, because only adoption requires it.

Observed reproduction

  1. Linux machine with uv available, no pipx, and no git-filter-repo.
  2. Run the v1.0.1 release installer targeting v1.0.1.
  3. Installer updates and pins openRepoShape successfully.
  4. Installer reports missing git-filter-repo and prints a pip --user fallback.
  5. General preflight passes and the installer reports the machine is ready.
  6. Repository adoption cannot proceed without separately installing git-filter-repo.

Source: install.sh at v1.0.1, filter_repo_step(), filter_repo_command(), and final preflight/readiness reporting.

Requested v1.1.0 fix

  • Support an already available uv as an isolated installer for the pinned git-filter-repo dependency, alongside pipx; for example, uv tool install git-filter-repo==2.47.0.
  • Preserve the dependency version pin and verify the installed executable is available on PATH, with actionable guidance when it is not.
  • Avoid recommending pip --user into an externally managed system Python; provide an appropriate isolated or platform-specific installation path instead.
  • Clearly distinguish general/scaffolding readiness from adoption readiness. If git-filter-repo remains unavailable, the final summary must explicitly say adoption is not ready and give the next command.
  • Preserve the documented boundary around privileged/system changes; do not silently install pipx, uv, or system packages.

Acceptance coverage

Test existing dependency, pipx-only, uv-only, neither installer available, installation failure, and successful installation with executable not yet on PATH. Verify readiness summaries remain accurate without treating adoption-only dependencies as required for diagnostics or scaffolding.

Requested by Brett Heap during the openRepoTools Triad migration on 2026-10-15. This issue records the installer improvement only; it does not authorize changing or republishing v1.0.1.

Activity

  1. added this to the v1.1.0 milestone on Oct 15, 2026
  2. brettheap commented on Oct 15, 2026

    @brettheap
    ContributorAuthor

    CLAIMED — lane openRepoShape-3, session b30e8b49-f249-4668-adb1-1dbfa93c09e1@Eagle, 2026-10-15T14:55:24Z, for #595

    Logged in lanes/log/openRepoShape-3.md at f3e1fd805682133005654b635ba20608bffa1e84.

    The three reads (lane-collision-protocol Rule 1):

    1. existing `CLAIMED —` comments on opensoft/openRepoShape#595:
       none
    2. `gh pr list --repo opensoft/openRepoShape --state all --search "#595"`, kept where the row or its body names `#595`:
       none
    3. `git ls-remote --heads git@github.com:opensoft/openRepoShape` branches naming `595` as a whole token:
       none
    
  3. added 7 commits that reference this issue on Oct 15, 2026
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

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions