Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: make Windows MSI default install path more conventional? #23848

Open
rawtaz opened this issue Feb 15, 2018 · 14 comments
Open

build: make Windows MSI default install path more conventional? #23848

rawtaz opened this issue Feb 15, 2018 · 14 comments
Labels
Milestone

Comments

@rawtaz
Copy link

@rawtaz rawtaz commented Feb 15, 2018

What version of Go are you using (go version)?

Haven't installed it yet, but 1.9.4.

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

Irrelevant.

What did you do?

Ran the installer and noticed the default install path.

What did you expect to see?

C:\Program Files\Go or some other more conventional and common path to where the files should be installed.

What did you see instead?

C:\Go

Comments

So, the default install path in the MSI installer is not great. Almost all software installers on Windows default to a base path of e.g. C:\Program Files\ or similar. It has (arguably, I'm not going to provide specific sources for this) for long been considered pretty bad practice to install stuff directly under C:\, and I haven't been able to find a reason as to why Go defaults to that location on Windows.

There's a somewhat related issue in #21609, in which @as does have a point for his use case of the default path. However, overall I think that convention and sanity (in terms of not putting stuff in one big pile under C:\) weighs more than being able to use \go as the path.

@as also points out that the Windows folder structure lacks coherence, and I agree with that - there's some seriously stupid things in there, like the ones he gave an example of. However, there's at least some value to having a folder structure at all, e.g. all user-installed programs being under a common folder. Imagine if you installed everything and put all user files under C:\, what a mess it would be.

So, I am asking, is there any specific reason that C:\Go was chosen as the default install path, rather than a more conventional one? If there's no very specific reason, why not change it to a more conventional default path on Windows?

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Feb 15, 2018

We have persistent problems with Windows path length limits (#22230, #21782, #18468, #3358, #10577, #17500, etc). IIRC, we placed it at "C:\Go" because it was shorter than "C:\Program Files\Go" and made the difference between the build working and not working. It's gotten better, but we still have open bugs in that area.

@bradfitz bradfitz added the OS-Windows label Feb 15, 2018
@bradfitz bradfitz changed the title Windows MSI default install path build: make Windows MSI default install path more conventional? Feb 15, 2018
@bradfitz bradfitz added this to the Unplanned milestone Feb 15, 2018
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Feb 15, 2018

@as
Copy link
Contributor

@as as commented Feb 16, 2018

Chime. The conventional paths may also contain spaces and parenthesis. You would also have to install the 32-bit binary toolchain in C:\Program Files (x86).

@rawtaz
Copy link
Author

@rawtaz rawtaz commented Feb 16, 2018

Yes, indeed it contains spaces, and yes that is one of the conventional paths.

As someone else said, you probably wouldn't install Go on linux in /go :)

@as
Copy link
Contributor

@as as commented Feb 16, 2018

As someone else said, you probably wouldn't install Go on linux in /go :)

That is where it goes on my linux machines. Most distributions have filesystem layouts comparable to the quality of Windows (e.g., /usr/bin vs /bin). Why complicate things with standards that don't have a single source of truth?

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Feb 17, 2018

IIRC, we placed it at "C:\Go" because it was shorter than "C:\Program Files\Go" and made the difference between the build working and not working. It's gotten better, but we still have open bugs in that area.

Correct. I also suspect that we had trouble with spaces in the file paths in the past, but that should be fixed too. So I think it is fine to install Go into "C:\Program Files" just like any other program. The only thing that comes to my mind is that "C:\Program Files" might not be writable when user using Go - so we need to make sure that we don't write into "C:\Program Files\Go" once installer has finished.

/cc @alexbrainman

I would love to have a go at fixing this, but I have to be truthful to myself :-) I have very little free time now. But I am happy to help when I can.

You would also have to install the 32-bit binary toolchain in C:\Program Files (x86).

I suspect installer should handle this by default. We just have to stop asking installer to install Go into c:\go.

Alex

@olegburov
Copy link

@olegburov olegburov commented Jul 14, 2019

The location C:\Go instead of C:\Program Files\Go also introduces confusion when crafting Windows image with Golang. See details here: docker-library/golang#288 (comment)

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Jul 21, 2019

The location C:\Go instead of C:\Program Files\Go also introduces confusion when crafting Windows image with Golang. See details here: docker-library/golang#288 (comment)

We all agreed that C:\Go needs to change. You don't need reminding us.

If you think it is important for this issue to be addressed, you should try and fix Go installer yourself. The code is in $GOPATH/src/golang.org/x/build/cmd/release/releaselet.go.

Alex

@lucastheisen
Copy link

@lucastheisen lucastheisen commented Oct 31, 2019

What about allowing the MSI to accept an install folder as an argument? This would be really useful for package managers like Chocolatey

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Oct 31, 2019

What about allowing the MSI to accept an install folder as an argument? This would be really useful for package managers like Chocolatey

We really don't like maintaining options whenever possible. The installer already gives the user options. We just set the default.

Does Chocolatey just download & run the Go installer? I would assume it's a package manager so it packages things and manages things. Or does Chocolatey run it in some headless mode where the user doesn't need to click next next next next?

Chocolatey could also just install the zip releases we make instead of the msi.

@lucastheisen
Copy link

@lucastheisen lucastheisen commented Nov 1, 2019

Chocolatey packages can do either, but the maintained package for go downloads and runs the MSI. By default, chocolatey supports an --install-arguments switch that will:

... pass to the native installer in the package

So we can hand off args to the MSI, but not if the MSI itself doesn't support it. It's true that the chocolatey package could switch the the zip as it's source, but then would have to deal with complications if you add additional steps that you take care of in the MSI. It would be ideal if you could support this, but if options aren't an option, then I will just have to do the install with lots of ansible instead.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Nov 2, 2019

@lucastheisen
Copy link

@lucastheisen lucastheisen commented Nov 7, 2019

@bradfitz , didn't know you had the WIX embedded in the go code... Now that I look, you already support INSTALLDIR so simply running like this works:

choco install --install-arguments="INSTALLDIR=C:\gofoo" golang

Thanks!

@xmha97
Copy link

@xmha97 xmha97 commented Jun 6, 2020

I think C:\Program Files\Go is better for the default installation path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.