Added nixpkgs_go_configure

[saksmt]

It's a mystery how it wasn't added yet since rules_docker require working go sdk and it doesn't work on NixOS because it's being downloaded as a binary

[mboes]

Thanks for the contribution. This should be useful for rules_haskell, where we simply set go_register_toolchains(go_version = "host") inside a Nix shell. Generally looks good.

[thufschmitt]

Really cool 👍 As @mboes said, we currently have a workaround (using go_version = "host"), but this is much cleaner.

This breaks the tests however − which unfortunately isn't caught by the CI because it is broken 😕 − because they still use the very old bazel 1.1 which isn't compatible with the version of rules_go used. I tried updating to 2.0 but this breaks the python tests. Maybe we can find something in between so that we can merge this PR quickly and fix the python stuff later

[aherrmann]

I tried updating to 2.0 but this breaks the python tests. Maybe we can find something in between so that we can merge this PR quickly and fix the python stuff later

I took a look at that failure. Fortunately it was easy to work around the issue: #108

[thufschmitt]

Just a couple of comments that I forgot to submit earlier today

[saksmt]

Pulled latest master, fixed docs (see comment below) and improved nix expression.

Fix in docs:
Unfortunately go_register_toolchains uses some sort of reflection/introspection and collects all rules filtering out those that aren't go_sdk so we can't just tell users to call nixpkgs_go_toolchain (since we can't make it a rule and otherwise we can't find out if nix is present or not) and then go_register_toolchains and expect everything to work fine on both nix and non-nix environments, so hacks around rule generation with dynamic loading still needed (that one I mean) 🙁 . That means average usefulness of this code drastically drops, but still it's way better then to have go installed on local machine for non-go developer just to be able to build docker images

[thufschmitt]

It's quite unfortunate that we can't just call the rule and let the toolchain resolution do its job, but I agree that having this rule is still better than using it from the environment.

(wrt the hack you mention, it can be simplified a bit: see tweag/rules_haskell@bb9ef6b. Maybe some of this could even be upstreamed in rules_nixpkgs)

[thufschmitt]

Thanks!