api/golang@1.18.1 fails to build for external consumers: undefined path_compression.ComputeContentHash

[parithosh]

Summary

The latest release 1.18.1 of github.com/kurtosis-tech/kurtosis/api/golang cannot be built by external Go consumers. Compilation fails with:

github.com/kurtosis-tech/kurtosis/api/golang@v1.18.1/core/lib/enclaves/enclave_context.go:762:39:
  undefined: path_compression.ComputeContentHash

Reproduction

mkdir kurtosis-test && cd kurtosis-test
go mod init kurtosis-test
cat > main.go <<'GOEOF'
package main

import (
    "context"
    "fmt"
    "os"

    "github.com/kurtosis-tech/kurtosis/api/golang/engine/lib/kurtosis_context"
)

func main() {
    ctx := context.Background()
    kCtx, err := kurtosis_context.NewKurtosisContextFromLocalEngine()
    if err != nil { fmt.Fprintln(os.Stderr, err); os.Exit(1) }
    info, err := kCtx.GetEngineInfo(ctx)
    if err != nil { fmt.Fprintln(os.Stderr, err); os.Exit(1) }
    fmt.Println(info.GetEngineVersion())
}
GOEOF
go get github.com/kurtosis-tech/kurtosis/api/golang@1.18.1
go build ./...

Tested with go 1.26.2 on darwin/arm64.

Root cause

api/golang/go.mod has:

replace (
    github.com/kurtosis-tech/kurtosis/grpc-file-transfer/golang => ../../grpc-file-transfer/golang
    github.com/kurtosis-tech/kurtosis/path-compression          => ../../path-compression
)

These local replace directives only apply inside the monorepo — they are ignored when api/golang is consumed as a module. External builds therefore resolve github.com/kurtosis-tech/kurtosis/path-compression to the latest tagged pseudo-version v0.0.0-20240307154559-64d2929cd265, which does not export ComputeContentHash. The function is referenced from core/lib/enclaves/enclave_context.go:762, so the build fails.

Suggested fix

Cut a tagged release of path-compression (and grpc-file-transfer/golang) that includes ComputeContentHash, then bump the require lines in api/golang/go.mod to that version and drop the local replace directives (or keep them but ensure the require versions can also build standalone).

Environment

• go version go1.26.2 darwin/arm64
• github.com/kurtosis-tech/kurtosis/api/golang v1.18.1
• Resolved path-compression v0.0.0-20240307154559-64d2929cd265

[parithosh]

Long-term fix options

The patch in #3074 unblocks external consumers, but it's a band-aid — the same class of breakage will recur the next time a path-compression (or grpc-file-transfer/golang) symbol referenced by api/golang lands without a corresponding require bump. The structural problem:

1. The replace directive hides the bug from local devs. Inside the monorepo, go build resolves path-compression to the local source via replace, so any newly added symbol Just Works. The pseudo-version in require is never actually exercised, so a stale pin produces no compile error — only external consumers feel it.
2. Bumping the pin is a manual, release-time chore with no enforcement. Nothing reminds you to bump it when you add a new symbol.
3. Pseudo-versions aren't a release contract. They're commit-pinned snapshots; backwards-incompatible changes to path-compression won't surface as version conflicts.

Options (rough order of preference)

(A) Inline path-compression and grpc-file-transfer/golang into api/golang.
Neither module appears to have external consumers outside this repo. The multi-module layout exists to support reuse that isn't happening, and it's the root cause of the replace-vs-require divergence. Folding the code into api/golang (or a shared internal/ package) eliminates the pinning problem entirely.

(B) Cut real semver tags for path-compression and grpc-file-transfer/golang.
Configure release-please in monorepo mode so each submodule gets its own tagged releases (e.g. path-compression/v0.1.0). Have api/golang depend on those tags instead of pseudo-versions. Then the go.mod is a real contract and downstream consumers can pin meaningful versions.

(C) Add a CI job that builds api/golang with the replace directives stripped.
Doesn't fix the structure, but makes the existing structure self-policing — you cannot tag a release with a stale pin if CI fails first. Roughly:

cp -r api/golang /tmp/external-build
cd /tmp/external-build
go mod edit -dropreplace=github.com/kurtosis-tech/kurtosis/grpc-file-transfer/golang \
            -dropreplace=github.com/kurtosis-tech/kurtosis/path-compression
go build ./...

(C) is cheap and high-value regardless of whether (A) or (B) is pursued — it would have caught the v1.18.1 breakage before tagging. I'd recommend doing (C) immediately and treating (A)/(B) as a follow-up architectural decision.

[parithosh]

@tedim52 for long term fix! its temporarily solved but i imagine we break it again someday