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.

Sign up for GitHub

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

Jump to bottom

cmd/go: install package for all users #33234

Closed
isaiahtaylor opened this issue Jul 22, 2019 · 4 comments
Closed

cmd/go: install package for all users #33234

isaiahtaylor opened this issue Jul 22, 2019 · 4 comments
Labels
FeatureRequest Issues asking for a new feature that does not need a proposal. FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Unplanned

Comments

@isaiahtaylor
Copy link

Global go get

As it is, go get installs to $GOPATH/src, traditionally /home/$USER/go/src. Unfortunately, this means that modules cannot be installed for all users, unless everyone shares a $GOPATH (and all have access to that directory). This would be very unconventional for Linux.

Since there is already a global $GOROOT/src, there should be an option to go get packages to that location, making them available for all users.

Use cases:

  • sysadmins who want to add a tool to the environment available for everyone
  • machines with multiple users for multiple functions can share packages

Solution:
Add a global flag to go get (e.g. go get -g) that installs to $GOROOT instead of $GOPATH.
@AlexRouSg
Copy link
Contributor

Do you only care about the executable or do you want the sources to be global too?

There is a GOBIN variable that lets you set where to put the executables.
https://golang.org/cmd/go/#hdr-Environment_variables

If you want the sources to be global, you can have multiple GOPATH directories e.g. GOPATH=/some/global/path:/home/$USER/go and go get should download to the first path, but build should search all paths. I'm not sure if this works in module mode tho.

@agnivade
Copy link
Contributor

In module mode, if you are running a go get outside a module, then the binary will be installed in GOBIN. So then, your binary becomes available for all users. But if you are talking about running a global install inside a module then #30515 is for that.

Regarding sharing packages, I believe it will take us back to GOPATH mode from module mode. Each module will always have it's own go.mod which will pin down it's version. Having a global package will break this as the version of the global package and in go.mod can go out of sync.

@ALTree ALTree added FeatureRequest Issues asking for a new feature that does not need a proposal. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Jul 23, 2019
@ALTree ALTree added this to the Unplanned milestone Jul 23, 2019
@ALTree ALTree changed the title cmd/go feature request: Install package for all users cmd/go: install package for all users Jul 23, 2019
@bcmills
Copy link
Contributor

bcmills commented Jul 25, 2019

The functionality you propose seems like it would overlap significantly with GOPROXY. In particular, a GOPROXY setting using a file:// URL can easily point to a shared read-only directory tree, from which individual users can go get files into their local GOPATH cache.

Do you have any particular use-cases in mind that cannot be satisfied using a combination of GOPROXY (to retrieve modules from the shared cache) and GOPATH + go mod download (to populate modules into the shared cache)?

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Jul 25, 2019
@gopherbot
Copy link
Contributor

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@golang golang locked and limited conversation to collaborators Aug 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FeatureRequest Issues asking for a new feature that does not need a proposal. FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
6 participants
@agnivade @ALTree @bcmills @AlexRouSg @gopherbot @isaiahtaylor