Honor CASINO_CONFIG_DIR and CASINO_DATA_DIR #47

New issue

Open

opened 2026-08-15 18:58:44 +00:00 by rosa · 2 comments

rosa commented

2026-08-15 18:58:44 +00:00

Owner

What to build

Let a player point the casino at a different home through the environment:
CASINO_CONFIG_DIR and CASINO_DATA_DIR, each falling back to the system's
usual place when unset. The reading belongs inside the constructor that asks
where a user's files go — the binary should not be the only thing that knows
what the variables are called.

This is what makes end-to-end tests possible at all. assert_cmd, assert_fs,
and predicates are already dev-dependencies and nothing in the tree uses them;
there is no test directory. Put them to work on the two things unit tests
cannot reach, because they are claims about the built binary rather than about a
function: that it honors the variables, and that a first run against an empty
home leaves a readable config behind.

Deliberately not in scope: a non-interactive flag for purge. Its decisions are
covered as a value by the housekeeping ticket, so an end-to-end purge test would
re-cover that ground while adding a feature invented to serve a test.

Relying on XDG_CONFIG_HOME instead was considered and rejected — the directory
crate honors it on Linux and ignores it on macOS, so a suite built on it would
pass in CI while quietly pointing at a real home elsewhere.

Acceptance criteria

Both variables redirect the binary, together or one at a time
Unset variables fall back to the system's usual locations, unchanged from
today
An end-to-end test runs the binary against a temp home and finds a config
written on first run
The variable names appear in one place, not at each call site
README documents both variables
CHANGELOG notes the new variables

Blocked by

## What to build Let a player point the casino at a different home through the environment: `CASINO_CONFIG_DIR` and `CASINO_DATA_DIR`, each falling back to the system's usual place when unset. The reading belongs inside the constructor that asks where a user's files go — the binary should not be the only thing that knows what the variables are called. This is what makes end-to-end tests possible at all. `assert_cmd`, `assert_fs`, and `predicates` are already dev-dependencies and nothing in the tree uses them; there is no test directory. Put them to work on the two things unit tests cannot reach, because they are claims about the built binary rather than about a function: that it honors the variables, and that a first run against an empty home leaves a readable config behind. Deliberately not in scope: a non-interactive flag for `purge`. Its decisions are covered as a value by the housekeeping ticket, so an end-to-end purge test would re-cover that ground while adding a feature invented to serve a test. Relying on `XDG_CONFIG_HOME` instead was considered and rejected — the directory crate honors it on Linux and ignores it on macOS, so a suite built on it would pass in CI while quietly pointing at a real home elsewhere. ## Acceptance criteria - [ ] Both variables redirect the binary, together or one at a time - [ ] Unset variables fall back to the system's usual locations, unchanged from today - [ ] An end-to-end test runs the binary against a temp home and finds a config written on first run - [ ] The variable names appear in one place, not at each call site - [ ] README documents both variables - [ ] CHANGELOG notes the new variables ## Blocked by - #45

rosa added the

ready-for-agent

label

2026-08-15 18:59:03 +00:00

rosa referenced this issue

2026-08-15 18:59:35 +00:00

Record how the casino finds its files #51

rosa added a new dependency

2026-08-15 19:01:51 +00:00

#51 Record how the casino finds its files

rosa added a new dependency

2026-08-15 19:05:34 +00:00