gps
gps copied to clipboard
sdboyer
Handle gopkg.in paths with e.g. "unstable" suffix
First, quick background - gps has a set of "deducers," which are the way that it extracts project roots from import paths. These are entirely analogous to what go get uses today. However, we need more from them than does go get: these deducers also set up logic that will create and ultimately manage interaction with a source repository on disk (which is kept in the cache area).
I implemented specialized handling in a custom deducer for gopkg.in, rather than relying on the HTTP go-get metadata, for several reasons:
- Most importantly, because it was the only way to translate as much as possible of the constraint system gopkg.in creates into gps' terms
- It let me normalize the import paths that differed only by constraint (e.g.
gopkg.in/yaml.v2andgopkg.in/yaml.v1) into the same underlying source. Two notes on this: a. I'm not fully sure this was the right decision, and could totally be convinced to back it out b. I can't remember exactly how far I got with doing this - it's a very awkward pattern that kinda breaks the model - To eliminate unnecessary HTTP requests (gopkg.in's patterns are predictable, so why not)
The error @rogpeppe reported in golang/dep#126 comes from here, where we're setting up the logic that will later create a source for the named path. (The comment is incorrect - the regex isn't wrong, it's just that I didn't handle the suffix case there.) The real issue that needs addressing is noted in the code that actually retrieves a list of possible versions from the source (repository), though - we just don't handle the unstable suffix.
IIRC, the basic issue is that I just don't have a clear sense of how we'd even map the notion of "unstable" onto semver/a version list. I also may have just kicked this can down the road. Either way, though, we need a fix now.
@kris-nova this is the one you were looking at, right? please don't hesitate to ask questions, or even just to spitball - whatever helps you get over the hump with it!
It definitely does. I think the question in my mind when I initially implemented this was, given that gopkg.in treats these import suffixes as general constraints rather than exact matches, should an -unstable suffix match just the literal suffix -unstable, or some wider set of versions.
Looking at niemeyer/gopkg#25, though, it seems like the exact matching is the way to go. So I think that makes this simpler :)
Nope, nobody's showed up yet to help. This is lower priority for me to work on myself than other things. If it has to fall to me to get done, it'll probably be a couple months.
Ah sorry, I totally missed my mention on this! I can try to take a look sometime next week, and follow up then!
