Add eng/install-scripts/microsoft-go-install.ps1

[dagood]

• For Create a PowerShell Microsoft Go install script intended for use in CI go#1324
• In the short term, this is how we could get Microsoft Go in our own pipelines and keep it up to date. https://github.com/microsoft/go-lab/issues/109

I started with the .NET install script and turned it into a Microsoft Go install script while generally keeping features/scenarios and making it work with tar.gz archives. I kept my changes in a separate commit.

From here, we can decide what we actually want to maintain and perhaps cut a lot.

A feature I didn't include is installing the "correct" Go based on the project. In .NET a global.json may specify a .NET version, in Go we could leverage the go.mod's toolchain go1.23.2 directive. However, there's no room for our revision -1/-2 here, so it wouldn't be totally reproducible. (It would have to download the newest revision we release of the matching 1.x.y.)

I ran this with these (all amd64):

• Windows:
  • PowerShell (most restrictive)
  • PowerShell Core
• Linux (Fedora)
  • PowerShell Core

[qmuntal]

Can we omit this command? We already explained how to install microsoftgoinstallscript in a previous section, and it should be necessary to reinstall it every time a command is executed.

[dagood]

I think "should" was a "shouldn't" typo, but actually I do think it's relatively necessary. 😄

The microsoftgoinstallscript binary itself contains the script text, so you need to reinstall it whenever you have the wrong version of it installed, and it's not easy to tell, so I think we need to include install in a lot more places than normal to try to make sure people don't stumble on this.

But... maybe the design is too simple, and we need a smarter user-focused command. E.g. a command that doesn't embed the script content and instead looks at go.mod/go.sum and downloads the right version of the script content. (Or maybe the current cmd is ok as a component, but we also need another cmd to wrap it in a friendly way?)

This cmd as it stands is basically an MVP for using a Go dependency to keep a PowerShell script up to date in a remote module, but I see some ways to improve this.

[qmuntal]

We should document whether prerelease versions are supported or not, i.e. 1.23rc1.

[qmuntal]

The package name is too verbose for my old eyes. Users will mainly want to install the CLI rather than using the small Go API in github.com/microsoft/go-infra/install/powershellscript. When the principal "product" is a CLI and not the Go API, it is common to not follow the usual pkgname/cmd/cliname convention but use cliname/pkgname instead. This way the CLI is easier to install (requires less typing!).

Also, the microsoftgoinstallscript cli can potentially be made more generic and install other script types. Even if we don't eventually do it, I don't see a lot of value on putting it under a folder named powershellscript, as we are artificially limiting the scope of the cli.

With all this in mind, this is my suggestion:

• Rename github.com/microsoft/go-infra/install/powershellscript to github.com/microsoft/go-infra/goinstallscript.
• Move all files in github.com/microsoft/go-infra/goinstallscript to github.com/microsoft/go-infra/goinstallscript/powershell.
• Move github.com/microsoft/go-infra/goinstallscript/cmd/microsoftgoinstallscript/main.go to github.com/microsoft/go-infra/goinstallscript.

If we do this, then installing the cli will look like this:

go get github.com/microsoft/go-infra/goinstallscript@latest

[qmuntal]

Meta question: can we omit the microsoft prefix from the script name and from the new package name? In the future we might want to support downloading the upstream toolchain using this same script and just changing a parameter (which will always default to the Microsoft toolchain). If that happens, then having the Microsoft prefix will feel strange.

I guess the Microsoft prefix is there to avoid conflicting with upstream tooling, but I don't think it will ever conflict. Google want provide a powershell script, and even if it did, users installing both could rename our script with whatever name they like.

[dagood]

users installing both could rename our script with whatever name they like.

Well, if they use the current util command to keep it up to date, they couldn't. 😄

I think giving it more general branding does sound reasonable. In fact, supporting upstream Go actually could make a lot of sense for this install scenario because it lets people easily run tests on both Microsoft Go and upstream Go in CI and locally.

[qmuntal]

Meta comment: I don't expect that we update the PowerShell script nor the microsoftgoinstallscript package often, maybe one or two times per year, if any. On the other hand, the go-infra is updated quite more often. Also, microsoftgoinstallscript doesn't depend on other go-infra packages.

With this in mind, I would suggest planting a go.mod file in install/powershellscript so that package gets promoted to being it's own module. Then we can version it independently of go-infra. Well, we are currently versioning go-infra, but I think we should definitely version microsoftgoinstallscript.

[dagood]

Huh, I've always assumed those still get versioned with the surrounding module, but finally saw https://go.dev/doc/modules/managing-source#multiple-module-source for how that works.

Yeah, we would produce a lot of useless dependabot update PRs for people if we didn't version it separately.

[qmuntal]

I'm afraid I don't get the use-case that this indirection tries to tackle. Why someone would want to install multiple versions of the script? How other steps would be necessary to accomplish that?

Also, this new go run approach precludes running goinstallscript in environments without go installed. I think it was a nice feature that before you could plant goinstallscript in a brand new environament and just execute it to install the powershell script. Note that we could support both use-cases by falling back to powershell.Content if exec.LookPath("go") fails.