Repository navigation
Go module is not go get-able: declared module path golang.a2z.com/... doesn't resolve #10
Description
Summary
The Go library under /golang cannot be installed with go get via any import path, which forces every Go integrator to vendor a manual copy of the source with a filesystem replace directive. This appears to be a leftover from the library's pre-donation packaging rather than an intentional choice.
Details
golang/go.mod declares:
module golang.a2z.com/demanddriventrafficevaluator
Fetching by the declared path fails — the vanity-import endpoint doesn't exist publicly:
$ go get golang.a2z.com/demanddriventrafficevaluator@latest
go: unrecognized import path "golang.a2z.com/demanddriventrafficevaluator":
reading https://golang.a2z.com/demanddriventrafficevaluator?go-get=1: 403 Forbidden
(a2z.com presumably served go-import meta tags inside Amazon's network, but returns 403 publicly.)
Fetching by the GitHub path also fails — Go requires the declared module path to match the requested one:
$ go get github.com/IABTechLab/DynamicTrafficEngine/golang@latest
go: parsing go.mod:
module declares its path as: golang.a2z.com/demanddriventrafficevaluator
but was required as: github.com/IABTechLab/DynamicTrafficEngine/golang
So there is no import path that works, and the standard installation flow described in the integration manual (§2.2, "install DTE evaluator library provided by the Buyer") isn't possible for Go consumers.
Suggested fix
Rename the module to match its hosting location:
- Change golang/go.mod to module github.com/IABTechLab/DynamicTrafficEngine/golang
- Update the internal import paths (golang.a2z.com/demanddriventrafficevaluator/... →
github.com/IABTechLab/DynamicTrafficEngine/golang/...) — mechanical find/replace across the /golang tree - Optionally tag a release so consumers get a semantic version instead of a pseudo-version
Alternative (if the golang.a2z.com name must be preserved): serve go-import meta tags publicly at that domain pointing to this repository. The rename is simpler and removes the dependency on Amazon-owned infrastructure.
Impact
Until fixed, every Go SSP integrating DTE must copy the source into their repo and maintain it by hand — no go get, no dependabot/renovate updates, no checksum verification against a module proxy.
Activity
belinday commentedon Aug 11, 2026
Workaround until this is fixed — a fork-style
replaceworks, because Go validates a replacement module's declared path against the left-hand side of the replace (the same rule that makes fork replaces work):With this in place the module fetches through the public proxy with sumdb-verified checksums, builds, and runs. (To pin a newer commit:
go list -m github.com/IABTechLab/DynamicTrafficEngine/golang@<commit>prints the pseudo-version to use on the right-hand side.)This shouldn't be the permanent answer, though:
replacedirectives only apply in the main module and don't propagate downstream. Any shared Go library that wraps DTE would force every one of its consumers to repeat this incantation — so the module-path rename requested above is still the right fix for the ecosystem.