Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: misleading error for a version following the module directive in go.mod #30145

Open
nim-nim opened this issue Feb 9, 2019 · 7 comments

Comments

Projects
None yet
4 participants
@nim-nim
Copy link

commented Feb 9, 2019

A module can not declare its own version in go.mod even though

  • this is a basic need, not everyone gets its code through a git dump
  • the json structure outputted by "go mod edit -fmt -json" clearly provides for it, and
  • the error message reafirms a version should be possible

module test/dummy v0.0.1

go: errors parsing go.mod:
go.mod:1: usage: module module/path [version]
```
@mvdan

This comment has been minimized.

Copy link
Member

commented Feb 9, 2019

What exactly are you trying to accomplish that you cannot do at the moment?

Are you proposing this change as an alternative to the use of tags, or as an addition to them?

How would the go tool find a particular version? Right now it just lists the tags and branches. With your method, presumably it would need to look at every single change made to the go.mod file, which would likely be much more work.

Also note that a "git dump" isn't always necessary. With the presence of public module mirrors, you'll be able to download specific versions of Go modules without needing to use any VCS: https://blog.golang.org/modules2019

@nim-nim

This comment has been minimized.

Copy link
Author

commented Feb 9, 2019

You can't rely on git tags or branches because go source files get routinely cut and pasted and moved and forked and whatever else people being people do, losing SCM metadata in the process (not to mention some git histories are huge and people deliberately trim them) so the only reliable way to track the version of a set of files is to read a module descriptor.

That's pretty much the same reason having the module name written explicitly in go.mod works, and relying on implicit info (directory hierarchy in GOPATH, URLs, git remotes) didn't work out.

go.mod finally made the module name explicit and reliable, but versionning is still not there.

Moreover when you need to manage piles of code, some in Go, others in something else, parsing a text descriptor is (relatively) easy, needing to run all the various language-specific tools to get versionning info is not.

This does not mean the go tool should forget about tag or branches, it should just write the result in go.mod so info does not get lost with scm metadata, and check go.mod info is consistent with what it sees in scm metadata when getting code (because if it is not consistent something is wrong, typically quick and dirty cut+paste+commit in the SCM).

@nim-nim

This comment has been minimized.

Copy link
Author

commented Feb 9, 2019

To give another perspective. I am trying to integrate Go in systems that focus on full-cycle software management. As Russ Cox wrote himself in https://research.swtch.com/deps the current Go tooling posture is pretty much limited to an outward-facing “what do I need to download to build this code”.

In a full-cycle management system, you also need to answer questions like “what is this code”, “what is its version”, “how was this binary built, and from what code”. So robust naming and versioning info is not limited to third party code, it also needs to cover the codebase that calls this third party code.

@oiooj oiooj added the modules label Feb 10, 2019

@bcmills bcmills changed the title A module can not declare its own version in go.mod cmd/go: a module can not declare its own version in go.mod Feb 12, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

not everyone gets its code through a git dump

That's true, but if you want to build in module mode you certainly do need a way to resolve versions to concrete modules.

We have a protocol for that, and that protocol communicates the versions in resource paths and .info files. See https://tip.golang.org/cmd/go/#hdr-Module_proxy_protocol.

@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

you also need to answer questions like “what is this code”, “what is its version”, “how was this binary built, and from what code”.

See debug.BuildInfo and #29814.

@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

As far as I can tell, the only problem reported here that is not covered by an existing issue is the error message from the parser.

@nim-nim

This comment has been minimized.

Copy link
Author

commented Feb 12, 2019

And the HDR protocol is useless to trace the versioning intent of the code author since it relies on generated files, the info itself is not present in the source files written by the code author. Somewhere all the cleverness of go get transformed sharing a plain version number with your code users into a massive infrastructure job.

Also, from what I see in the spec right now HDR forgot about the initial intent to help people share go code through plain fileservers, you'll need specific tooling to generate info files and the list element is an index that needs regeneration every time a new module is dropped in the repository (but I won't comment more about HDR since looking at it closely is the next step)

@bcmills bcmills changed the title cmd/go: a module can not declare its own version in go.mod cmd/go: misleading error for a version following the module directive in go.mod Feb 12, 2019

@bcmills bcmills added the NeedsFix label Feb 12, 2019

@bcmills bcmills added this to the Go1.13 milestone Feb 12, 2019

@bcmills bcmills self-assigned this Feb 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.