gnostic: New go.mod files causes issues
After renaming apps directory to cmd, it’s no longer possible to go install
any of the apps without cloning the repo.
There is no issues when cloning the repo and running go install from within the wanted cmd directory (e.g.: cmd/protoc-gen-openapi).
It’s strictly an issue concerning non-cloned use of the modules.
(go version go1.17 darwin/amd64)
How to reproduce
From a project with or without gnostic in go.mod.
When I run: go install github.com/google/gnostic/cmd/protoc-gen-openapi
I get:
no required module provides package github.com/google/gnostic/cmd/protoc-gen-openapi; to add it:
go get github.com/google/gnostic/cmd/protoc-gen-openapi
When I run: go get github.com/google/gnostic/cmd/protoc-gen-openapi
I get:
go get: github.com/google/gnostic/cmd/protoc-gen-openapi@v0.0.0-20220107061744-94bcf11351a5 requires
github.com/google/gnostic@v0.0.0: reading github.com/google/gnostic/go.mod at revision v0.0.0: unknown revision v0.0.0
When I run go install github.com/google/gnostic/cmd/protoc-gen-openapi@latest
outside of any repos
I get:
go install: github.com/google/gnostic/cmd/protoc-gen-openapi@latest (in github.com/google/gnostic/cmd/protoc-gen-openapi@v0.0.0-20220107061744-94bcf11351a5):
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.
So it seems there is no longer any way to get the apps, without cloning the gnostic repo first.
@timburks This seems like a hard issue to fix as it needs to be published, before we know if it’s fixed or not. A couple of ideas for a fix:
- Remove the go.mod files for each of the modules in cmd
- Remove the v0.0.0 and
replace
directive in all the go.mod files in cmd
What are the benefits of having a go.mod for each command? I may be missing something, but as far as I understand, it makes sense for tighter dependency control of each command. But is this needed or even wanted in this case? Doesn’t it actually make more sense to have 1 go.mod file in the root, since everything is more or less interdependent, which makes it even more necessary to not have 2 commands installed from 2 different versions of the repo.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 31 (15 by maintainers)
However, it has also accumulated experience for us. For me, this is a bumpy but quite pleasant open source contribution
@morphar Yes, I see what you mean. I’m sorry for the current situation. It seems that we can only release one version to fix the problem that the
@latest
version cannot be specified.