gimme awareness of available versions

[philpennock]

At present, the gimme script knows very little about what versions of Go exist and are potentially available. There's testdata, which has that. At a layer above gimme, travis-ci/travis-build is doing some substitution work to make 1.9.x work, by knowing what .x should be at any given point in time.

People keep expecting this to be part of travis-ci/gimme itself, which is absolutely fair. It looks like gimme, it smells like gimme, they're filing bugs against gimme and it would be useful for gimme to handle this.

Should travis-ci/gimme handle this?

1. No, keep things as they are
2. Detect .x and error out with a diagnostic explicitly pointing towards something higher up, suggesting travis-build.
3. Implement version tracking and caching as part of gimme itself, or perhaps just ability to spot in-repo data when run from a repo?
4. Something else?

[meatballhat]

I'm not sure how to interpret the 👍 reactions given 4 options 😁.

I would be OK with internal version availability awareness under certain conditions, and I think I would even be OK with the kind of rudimentary aliasing that's done at the travis-build level. Things that I would like to avoid:

• 🚫 automatically downloading and writing stuff somewhere when:
  • responding to query-like commands such as gimme list
  • installing/activating a requested version
• 🚫 supporting aliasing or version matching beyond .x style

[philpennock]

Note that a month before I filed this issue, I merged a contribution adding -k/--known to gimme, which does probe remotely. We have that already, it's not part of --list though. So this proposal somewhat skates around the edges of what you want to avoid, but I think this proposal fits into the design we have:

Idea sketch: gimme --known should cache to a file ~/.gimme/known.json (or plain text, one-per-line); by default, don't re-probe if the file is less than an hour old, to provide some build system caching. Add --force to always re-probe. Have --known use that file by preference if it exists, so we basically are making the existing command faster normally, at expense of not immediately getting the very latest versions of Go.

With this, we can say that if and only if the requested version contains .x then we'll do an implicit gimme --known. So we do automatically download a list (if needed) when installing a requested version, but only if asked for .x, not otherwise. And since gimme is inherently all about downloading and caching Go versions, so any install command can potentially download data, this does not seem to me to add unnecessary network access. The list is going to be a few KB at most, whereas the Go version to be downloaded will be around 100MB.

[AlekSi]

I'm not sure how to interpret the 👍 reactions given 4 options.

I think as "yes, we agree that is a problem worth discussing".

[AlekSi]

See also travis-ci/travis-build#1295. Now it looks like travis-build depends on gimme's testdata.