modprox / mp

Private Go Module Proxy
https://modprox.org
BSD 3-Clause "New" or "Revised" License
16 stars 1 forks source link

Allows non-semver versions #123

Open deadok22 opened 5 years ago

deadok22 commented 5 years ago

Modprox should only add semver-versions or pseudo-versions of modules.

I think the behavior should be similar to that of go get: resolve a non-semver tag to a revision and add the module by its pseudo-version.

See this and this for more info on pseudo-version handling.

ovesh commented 5 years ago

@deadok22 as I understand this issue, the requirements are that users will be able to specify versions in /modules/new in a way similar to go get and have modprox resolve them correctly, as specified in the standard:

go get github.com/gorilla/mux@latest    # same (@latest is default for 'go get')
go get github.com/gorilla/mux@v1.6.2    # records v1.6.2
go get github.com/gorilla/mux@e3702bed2 # records v1.6.2
go get github.com/gorilla/mux@c856192   # records v0.0.0-20180517173623-c85619274f5d
go get github.com/gorilla/mux@master    # records current meaning of master

I think this is difficult, since there's no single way of resolving what a pseudo version is ; non-github may behave differently. Further, I think the main use case is just adding a pre-modules repo as a dependency, so I'd like to make it easier to just do that.

/mods/find brings us close, but has a few shortcomings. I'm going to try fixing those in #173.

Please correct me if I misunderstood what this issue is about.

deadok22 commented 5 years ago

@ovesh apologies for a delayed response - I was on vacation.

Yes, the idea is to have the same UX go get provides.

there's no single way of resolving what a pseudo version is

The algorithm for generating a pseudo-version given a version string is kind of described here (and, yes, it's not exactly simple :) ).

non-github may behave differently

Why would version resolution have anything to do with a particular repository hosting platform? (I haven't read the go get implementation, so I may be wrong on this one)

ovesh commented 5 years ago

I discussed this offline with @deadok22. The request here is that

  1. /new will prevent users from registering arbitrary strings as versions
  2. /new will resolve things like @master, @$COMMITSHA, and @$TAGNAME to a pseudoversion, similar to how go get does it.

I'm going to look at go get source to see how it handles it. We'll need to also correctly handle internal repos.