Specify Go nixpkgs package from `nixpkgs_go_configure`

[ar3s3ru]

Is your feature request related to a problem? Please describe. Currently, the nixpkgs_go_configure code is using go package to download the toolchain. The version of the toolchain is based on the version of nixpkgs:

• In 21.11, it's 1.16.5 (source: https://github.com/NixOS/nixpkgs/blob/nixos-21.11/pkgs/development/compilers/go/1.16.nix#L273)
• In unstable, it's 1.17.7 (source: https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/compilers/go/1.17.nix#L276)

This is rather implicit and opaque to a user, and the version downloaded must be checked using nix search or https://search.nixos.org/packages, which is not ideal.

Describe the solution you'd like Add a version or package parameter to nixpkgs_go_configure to specify explicitly the Go version to track.

E.g. with version

nixpkgs_go_configure(
    repository = "@nixpkgs",
    sdk_name = "nix_go",
    version = "1.17",  # Will use `go_1_17` package in the generated `nix_file`
)

E.g. with package

nixpkgs_go_configure(
    repository = "@nixpkgs",
    sdk_name = "nix_go",
    package = "go_1_17",
)

[aherrmann]

Thank you!

Add a version or package parameter to nixpkgs_go_configure to specify explicitly the Go version to track.

Other rules_nixpkgs rules provide an attribute_path attribute for that purpose, e.g. nixpkgs_java_configure. The motivation is that a selector like go_1_17 or jdk11.home is called an attribute path. It would make sense to use the same name for consistency.

[ar3s3ru]

@aherrmann I see... so this would be something like this?

nixpkgs_go_configure(
    repository = "@nixpkgs",
    sdk_name = "nix_go",
    attribute_path = "go_1_17",
)

My only concern with attribute_path could be kind of unclear for new users that it affects the toolchain version. Although this can be fixed with proper documentation 😅

[aherrmann]

@aherrmann I see... so this would be something like this?

Yes, exactly. :)

My only concern with attribute_path could be kind of unclear for new users that it affects the toolchain version. Although this can be fixed with proper documentation sweat_smile

That's true. Yes, a sentence about this in the docstring of nixpkgs_go_configure would be a good way to address this.

To elaborate a bit on why I'm hesitant towards version: The trouble with something like version is that doesn't really match how nixpkgs works. On the one hand, nixpkgs will only provide a restricted set of versions, e.g. a user may be tempted to request version = "1.15" but nixpkgs may only provide go_1_16|17|18. On the other hand, there is no guaranteed mapping between versions and attribute-paths, only convention, e.g. there is go_2-dev, but no go_2 (as of nixpkgs 19d6e349b). Also, different attribute paths may imply other differences than just version, e.g. an overlay may introduce go_1_17_debug or something along those lines. And, attribute_path is not the only attribute that could impact the version, nix_file and nix_file_content could do the same.