Skip to content

feat(cli): add --cwd DIR to run against another project (closes #69) - #80

Merged
shauryagangrade merged 1 commit into
shauryagangrade:mainfrom
dchaudhari7177:feat/cwd-flag
Aug 14, 2026
Merged

feat(cli): add --cwd DIR to run against another project (closes #69)#80
shauryagangrade merged 1 commit into
shauryagangrade:mainfrom
dchaudhari7177:feat/cwd-flag

Conversation

@dchaudhari7177

Copy link
Copy Markdown
Contributor

Closes #69.

What

gcode --cwd DIR, the equivalent of git -C:

gcode --cwd /some/project

The banner shows /some/project, .gcoderc is read from there, and every tool resolves paths against it.

The ordering is the whole feature

The chdir runs immediately after parse_args, before load_env(). That placement is what makes the acceptance criteria hold: .gcoderc discovery (load_config(project_root=os.getcwd())), ui.banner(..., os.getcwd()) and all the tools resolve against the working directory. A chdir performed any later leaves them describing different projects within one session — config from the launch directory, tools operating in the target.

So rather than assert the banner text, the test observes the working directory from inside load_env — the first call after the chdir — which pins the ordering directly:

monkeypatch.setattr("gcode.cli.load_env", _record)   # records cwd, then raises

Errors

A bad --cwd goes through parser.error(): one line on stderr, exit 2, no traceback — the same treatment as other bad input. OSError covers both a missing directory and a path that turns out to be a file, and the message carries strerror so the two are distinguishable:

gcode: error: --cwd '/no/such/project' is not usable: No such file or directory

Tests

Five in tests/test_cli.py:

  • --help lists the flag
  • the chdir is observed from load_env, proving it precedes config loading
  • without the flag the directory is untouched
  • a missing directory exits 2 with no traceback
  • a path that is a file exits 2

Each restores the original cwd in a finally, so a failure can't leak into later tests. Two fail on main (checked by stashing only gcode/cli.py).

Verification

pytest tests/test_cli.py — 15 passed. ruff check clean.

Full suite on this branch: 57 passed, 2 failed — the 2 are test_tools.py::test_grep / ::test_grep_ignore_case, which fail on a Windows checkout of main for an unrelated reason, sent separately as #78.

The issue mentions load_config(project_root=...) from #48; that already exists on main and needed no change, since it reads os.getcwd() at call time.

…yagangrade#69)

GCode always operated in the directory it was launched from, so pointing it
at another project meant cd-ing there and back. --cwd DIR does what git -C
does.

The chdir happens immediately after parse_args and before load_env(), which
is the ordering that matters: .gcoderc discovery (load_config(project_root=
os.getcwd())), the banner and every tool resolve paths against the working
directory, so a chdir performed any later would leave them describing
different projects in one session.

A bad --cwd goes through parser.error() -- one line, exit 2, no traceback --
matching how the CLI reports other bad input. OSError covers both a missing
directory and a path that is a file, and the message carries strerror so the
two are distinguishable.

Tests: five in test_cli.py -- --help lists the flag; the chdir is observed
from load_env, proving it precedes config loading; the directory is untouched
without the flag; and a missing directory and a file both exit 2. Two fail on
main.
@shauryagangrade
shauryagangrade merged commit 370352d into shauryagangrade:main Aug 14, 2026
6 checks passed
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.

[Feature]: --cwd DIR flag to start a session in a given directory

2 participants