Repository navigation
Decide: dl.py structural refactor plan #54
Description
Question
How should dl.py (1,291 lines, ~50 top-level functions) be split?
Decide the module boundaries and how far to go. Candidate seams from the scoping survey:
- completion cache (read/write/refresh,
update_cache_background) - devpod shell-out wrapper (
run_devpod,list_workspaces, status/context calls) - spec parsing (
OWNER_REPO_PATTERN, workspace-id derivation, sanitization) - CLI entry / dispatch (
main(), flag handling)
Also decide: what happens to the 2,535-line test/test_dl.py (split alongside? leave and re-point imports?), whether the duplicated git helpers (dl.remote_branch_exists vs BranchManager.remote_branch_exists, dl.get_remote_branches vs BranchManager.get_remote_branches) and the triplicated XDG-path logic (dl.py:48, config.py:12, storage.py:11) consolidate as part of this plan, and the PR slicing (one move-PR per module?).
The output is a refactor plan sharp enough to graduate into build tickets.
Activity
blooop commentedon Aug 7, 2026
Ruled out of scope by #53 (Rust rewrite: go), per this ticket's own stated terms — "Go → the refactor ticket is ruled out of scope here."
Deciding module boundaries for a
dl.pywe are replacing is wasted motion: the seams this ticket would pick (completion cache, devpod wrapper, spec parsing, CLI dispatch) get re-picked from scratch as thedevlaunch-core/dlsplit, under the binding invariant thatdlholds no logic beyond arg parsing and rendering. The duplication this ticket catalogued —dl.remote_branch_existsvsBranchManager.remote_branch_exists,dl.get_remote_branchesvsBranchManager.get_remote_branches, and the triplicated XDG-path logic atdl.py:48/config.py:12/storage.py:11— is worth carrying forward as input to the core's module design, not as a Python refactor.Closed, not resolved: a scope boundary is not a step on the route.