Skip to content

docs: Fix broken go install instructions (replace directive) - #26

Open
jgmcalpine wants to merge 2 commits into
lightninglabs:mainfrom
jgmcalpine:docs/fix-go-install-replace-directive
Open

docs: Fix broken go install instructions (replace directive)#26
jgmcalpine wants to merge 2 commits into
lightninglabs:mainfrom
jgmcalpine:docs/fix-go-install-replace-directive

Conversation

@jgmcalpine

Copy link
Copy Markdown

go install github.com/lightninglabs/lnget/cmd/lnget@latest fails on a clean machine:

go: github.com/lightninglabs/lnget/cmd/lnget@latest (in github.com/lightninglabs/lnget@v1.1.0):
        The go.mod file for the module providing named packages contains one or
        more replace directives. It must not contain directives that would cause
        it to be interpreted differently than if it were the main module.

(go version go1.25.6 darwin/arm64, macOS/Linux)

Root cause: go.mod contains:

replace google.golang.org/protobuf => github.com/lightninglabs/protobuf-go-hex-display v1.33.0-hex-display

which its own comment notes is required for lnd v0.20.0-beta's custom protobuf (UseHexForBytes) — a real dependency, not something to remove. go install pkg@version doesn't honor replace directives for remote installs, so this can't work as currently documented. I didn't touch go.mod since the replace looks intentional and necessary; happy to help if there's a preferred way to surface this, but kept this PR scoped to docs.

Fix: updated all four places I found this instruction to build from a local clone instead, which I verified works.

Testing: this is a docs-only change — no .go files touched, so make tidy-module-check / make unit / make lint produce no different output. I did verify the new instructions themselves work on a clean clone.

While testing, I also found the Dockerfile's golang:1.22-alpine base predates go.mod's current go >= 1.25.0 requirement — bumped to golang:1.25-alpine. Since this is the kind of thing that goes stale again as go.mod changes, I also added an explicit actions/setup-go step (reading the version from go.mod) to the GitHub Actions example, which previously had no version pin and was relying on the runner's default.

One observation, not part of this PR: the broken instruction was duplicated across all three files, which suggests drift risk if it needs to change again, it might be worth a single canonical install snippet the others reference. Happy to take a pass at that separately if useful.

I hit this while building an L402 demo against this tool: [https://github.com/jgmcalpine/headless-records-l402-demo], happy to link it if useful context.

go.mod requires go >= 1.25.0; the example's golang:1.22-alpine base
predates that and fails to build. Also pins the CI example's Go
version via actions/setup-go reading go.mod, so it can't drift the
same way again.
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.

1 participant