fix(generate): use relative paths for env vars in generated README

[mikeland73]

Summary

Fixes #2178.

devbox generate readme rendered plugin-provided environment variables with their fully expanded absolute paths. For example, enabling the postgresql plugin produced a README containing:

PGDATA="/home/carloratm/ooo/oha/.devbox/virtenv/postgresql/data"
PGHOST="/home/carloratm/ooo/oha/.devbox/virtenv/postgresql"

This leaks machine-specific paths — including the user's home directory / username — into a file that is typically committed to the repository.

The generated README already strips the absolute project directory out of scripts via configfile.Scripts.WithRelativePaths(projectDir). Environment variables were the one place this wasn't applied, because Config().Env() expands included-plugin env values to absolute paths before they reach the template.

Fix

Apply the same relative-path treatment to env var values before rendering: replace the absolute project directory with ., so the example above becomes:

PGDATA="./.devbox/virtenv/postgresql/data"
PGHOST="./.devbox/virtenv/postgresql"

This is intentionally consistent with the existing Scripts.WithRelativePaths behavior (same strings.ReplaceAll(value, projectDir, ".") transformation), and matches what was requested on the issue:

It would indeed be nice, when the generated README.md file only has relative references.

Values that don't contain the project dir (e.g. PGPORT="5432") are left untouched.

How was it tested?

• Added internal/devbox/docgen/docgen_test.go covering: project-dir substitution, that the input map is not mutated, and that an empty project dir returns env unchanged.
• go test ./internal/devbox/docgen/ passes; go vet and gofmt are clean.

cc the original reporter (the issue's author account has since been deleted) and @ametad, who reconfirmed the request on the issue.

---

Generated by Claude Code

[Copilot]

Pull request overview

This PR fixes devbox generate readme so that plugin-provided environment variables rendered into the generated README use project-relative paths instead of fully expanded absolute paths, avoiding leakage of machine-specific directories/usernames.

Changes:

• Apply project-dir-to-. substitution to generated README env var values (mirroring existing scripts behavior).
• Add focused unit tests for env var relative-path handling (substitution, non-mutation, empty project dir behavior).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
internal/devbox/docgen/docgen.go	Adds env var path relativization before README template rendering.
internal/devbox/docgen/docgen_test.go	Adds tests covering the new env var relative-path behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ametad]

Could someone with enough rights, review this? It would be very nice if this could be implemented.

[mikeland73]

@claude please review this PR for correctness, and flag anything that would block merging.

[claude]

Claude finished @mikeland73's task in 1m 7s —— View job

---

Review: fix(generate): use relative paths for env vars in generated README

• Gather context (read diff, changed files, CLAUDE.md)
• Review docgen.go changes for correctness
• Review docgen_test.go for coverage/quality
• Check Copilot review comments for validity
• Run tests / vet / gofmt
• Post final review

Summary

This is a correct, well-scoped fix. Config().Env() (internal/devconfig/config.go:352) expands plugin env vars (e.g. PGDATA, PGHOST) to absolute paths via OSExpandIfPossible, and until now GenerateReadme (internal/devbox/docgen/docgen.go:60) passed that straight to the template — leaking the machine's absolute project path/username into a file that's normally committed. The new envWithRelativePaths helper mirrors configfile.Scripts.WithRelativePaths (internal/devconfig/configfile/scripts.go:35) by doing strings.ReplaceAll(value, projectDir, ".") on each env value, which is the same technique already used for scripts, so the two code paths stay consistent.

Correctness

• The map is copied rather than mutated in place, and the original Config().Env() map is untouched — verified by the "does not mutate the input map" test.
• The projectDir == "" guard at docgen.go:74 returns maps.Clone(env), which is actually safer than the existing Scripts.WithRelativePaths: that function has no such guard, and strings.ReplaceAll(s, "", ".") (an empty old string) inserts . between every rune rather than being a no-op. This PR's version avoids that latent footgun for the env-var path, though it means the two helpers aren't byte-for-byte identical in behavior at that edge case — worth knowing, not a blocker since ProjectDir() shouldn't realistically be empty here.
• Values without the project dir (e.g. PGPORT="5432") pass through unchanged, as intended.

On the two Copilot comments

• "returns a copy" doc comment vs. empty-projectDir case: already addressed — the current code calls maps.Clone(env) in the empty-projectDir branch, so the doc comment is now accurate (a copy is always returned). Nothing to do here.
• Real-looking username in test fixture: already addressed — the test now uses /home/user/myproject rather than the original carloratm example from the issue. Nothing to do here.

Both prior review comments appear to have already been resolved in the current revision.

Not verified

I wasn't able to execute go build/go test/go vet/gofmt in this sandbox (the tool calls required approval that wasn't available non-interactively). I did read the test file and the implementation closely; the logic is straightforward and the tests look correct by inspection, but automated verification didn't run. If you want me to actually execute the test suite, the --allowedTools for go test/go build/go vet would need to be enabled for this job.

Verdict

No correctness issues found that would block merging. The implementation is a minimal, consistent fix matching the existing Scripts.WithRelativePaths pattern, with a reasonable test suite covering substitution, non-mutation, and the empty-projectDir edge case.