Create a Go (dep) constraint calculator

[sdboyer]

https://semver.npmjs.com/ exists, and it's great. We should have an equivalent. Not because NIH or vanity, but because there are real differences in the ecosystems:

1. We allow a diversity of constraint types - branches, non-semver tags, revisions
2. There are subtle differences in how compatibility range operators (~, ^, etc.) work, especially with prereleases and below 1.0.0
3. There's also cross-type matching, where e.g. different tags can match each other - or branches - if they happen to point at the same underlying immutable revision.

Gophers need a tool that tells them exactly how dep will behave, not how it probably sorta might. So, we need our own.

gps provides most of the facilities for doing this already (though it's not importable right now - #575). My back-of-the-envelope estimate is that the unique business logic in a backend server that does this would be about 200 LoC. Most of the work will be making a decent frontend.

If someone's interested in working on this, please indicate as much here, and we can flesh out requirements a little more.

[sdboyer]

To be clear, this is a totally standalone project, and would not be at all a part of dep. But we've only got the one queue, so until such a project gets rolling, this is a reasonable place to put a ticket 😄

[nijaru]

Are you looking for a website and a command line tool?

[sdboyer]

Ooh. Interesting.

I was definitely picturing a website, but both would be valuable. I suspect they could be structured pretty similarly, and probably reuse code.

[ralphg6]

https://github.com/Masterminds/semver

[sdboyer]

@ralphg6 yes, we depend on that library already. As such, it would necessarily be a part of the solution - but it does not independently solve the problem.

[ibrasho]

@sdboyer : Do we still have plans for a global package registry like crates.io, npmjs.com or packagist.org? Or is this no longer needed? (Just thinking where this could be hosted...)

[sdboyer]

@ibrasho yes, though still not anytime in the immediate future. A service like this may end up being rolled into that (there are nontrivial issues here with having a SourceManager run forever), but the backend part of this, at least, should be such a small thing that there's no reason to wait.

[thedevelopnik]

I'm probably not the one to start this but would love to help out with it whenever someone does get it started.

[niranjan92]

@sdboyer as we don't have a centralised package registry, how will the backend fetch the list of valid versions? Would we query github for a list of tags and branches and cache the results in some way?

[sdboyer]

@niranjan92 Yes, we query the upstream. The SourceManager has facilities for doing exactly that.

Caching it would probably be wise. That's actually likely to be the trickiest part in all this, as the SourceManager is not currently designed for use in long-lived processes, and it already does cache - but that cache is permanent and un-expirable. The simplest way around this for now would probably be to just set a reasonable lifetime (idk, 30 minutes?) for each SourceManager, then kill and recreate it.

[niranjan92]

@sdboyer hi was able to get the basic site up http://gosemver.initrc.com/ . 😄. Although getting it up was a bit tricky as gps is an internal package. Needs more work on UI and caching.

[sdboyer]

oh, sorry, I should've updated this issue to note that gps has been made public on tip!

in any case, I'll have a look this week - thank you for putting in the work!