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:

  1. Remove the go.mod files for each of the modules in cmd
  2. 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)

Most upvoted comments

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.