Reimplement as a Go binary

[smashwilson]

An idea that @rgbkrk and I have been tossing around.

Pros

• Single-binary, zero-dependency binary that's easy to install.
• Can use real JSON and https libraries to implement things like ls-remote robustly without needing to resort to ugly curl and sed pipelines.
• No need to worry about preserving cross-shell compatibility.

Cons

• dvm use can't be done directly because we aren't sourced into the shell; we'll need to do eval hacks like docker-machine env uses.
• Can't leverage nvm source as a reference.
• It means rewriting all of our existing work.

[rgbkrk]

What do you think about calling it goblin (go bin manager).

There's always the hybrid approach of dvm + goblin, where we package up the binary on the side. Then I imagine we can write dvm.ps1 or whatever (ping @carolynvs, @DonSchenck), relying on goblin for cross platform functionality.

[carolynvs]

On Windows using wrapper scripts is pretty normal. I think it would have a better user experience for the lowest common denominator too (cmd), because with just the binary (a la docker-machine env) they have to copy/paste the output and run it manually which is awkward.

[smashwilson]

What do you think about calling it goblin (go bin manager).

Like as a generic thing? The problem with that is getting it to handle install and ls-remote generically. It seems like every binary we'd want to support would have a different versioning and release strategy. We could bake in GitHub releases support, but our very first use case, Docker, doesn't follow that, so...

I like the name, I'm just not sure how the details work out there.

There's always the hybrid approach of dvm + goblin, where we package up the binary on the side.

👍 I do like this idea. Of course, we have the problem of packaging the binary. I'd rather not check it in to git if we have a different way to ship it with dvm...

[smashwilson]

On Windows using wrapper scripts is pretty normal. I think it would have a better user experience for the lowest common denominator too (cmd), because with just the binary (a la docker-machine env) they have to copy/paste the output and run it manually which is awkward.

✨ Cool. Sounds reasonable on the Windows end, then.

[carolynvs]

As I'm working on dvm.ps1 I'm really wishing we had a go binary. 😄 I'm going to take a day and take a stab at it.

[rgbkrk]

Feel free to cargo cult from, e.g. https://github.com/aktau/github-release.

[carolynvs]

Any suggestions for how the go binary should indicate to the shell wrapper that it should set some environment variables?

• Magic output. Shell wrapper will look at the output for commented out environment variable commands and run them

  # Lots of output that the wrapper ignores
  # export DOCKER_HOST=tcp://104.130.0.192:2376  (okay run this line)

• Dump to a file in the .dvm directory and run what's in there

• ?

[rgbkrk]

Assume we can eval things that are on stdout?

[rgbkrk]

(Yes I'm bad)

[carolynvs]

I don't think eval will work. Docker machine currently can't tell if it's running on cmd or powershell, just the os which is why they make you pass in --shell to the docker-machine env command.

So it will be up to the wrapper script to grab the key/values and set them.

EDIT: I'm a dork. The wrapper can pass that in when it calls the go binary. 😄

[rgbkrk]

Well also we can build specific things on windows vs Linux vs OS X, see carina for that. As for detecting powershell vs cmd, well yeah you're right there and dvm can say what shell it was invoked from.

[carolynvs]

Unless you are set on eval'ing the output, I'm going to try first to place a file in .tmp and have the wrapper just look for that after commands and run it. I notice that dvm use has a silent flag which suppresses all output which eval would break.