Skip to content
This repository was archived by the owner on Apr 13, 2023. It is now read-only.

Allows non-semver versions #123

Open
deadok22 opened this issue May 15, 2019 · 3 comments
Open

Allows non-semver versions #123

deadok22 opened this issue May 15, 2019 · 3 comments

Comments

@deadok22
Copy link
Member

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 ovesh assigned ovesh and unassigned ovesh Aug 29, 2019
@ovesh
Copy link

ovesh commented Aug 30, 2019

@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/[email protected]    # 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
Copy link
Member Author

@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
Copy link

ovesh commented Sep 17, 2019

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants