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
runtime: add GOPATH() string #19451
Comments
Note that:
|
Oh, it even says that at the top of the runtime package docs:
What are you trying to do? Does build.Default.Import (https://golang.org/pkg/go/build/#Context.Import) solve your problem? |
Ah, right, so the result would be []string.
GOROOT() returns the compile time value if there isn't a run time value.
Seems like a GOPATH() could have the same utility.
In my particular case, I'm writing a lightweight dotfiles package manager.
The repo remains on disk to pull updates made across multiple development
machines. There are dot files in the repo not built into the executable
that need to be read, relative to GOPATH.
…On Tue, Mar 7, 2017 at 6:53 PM Brad Fitzpatrick ***@***.***> wrote:
Oh, it even says that at the top of the runtime package docs:
The GOARCH, GOOS, GOPATH, and GOROOT environment variables complete the
set of Go environment variables. They influence the building of Go programs
(see https://golang.org/cmd/go and https://golang.org/pkg/go/build).
GOARCH, GOOS, and GOROOT are recorded at compile time and made available by
constants or functions in this package, but they do not influence the
execution of the run-time system.
What are you trying to do? Does build.Default.Import (
https://golang.org/pkg/go/build/#Context.Import) solve your problem?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#19451 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD5VsQ-6kx-NnqXJxKU2HhXSl4Upyguks5rjhg-gaJpZM4MWQYx>
.
|
Okay, sounds like go/build and friends are what you're looking for then. This isn't something we want to add to the runtime package, since it's not a runtime thing. |
Doesn't that also apply to runtime.GOROOT()?
…On Tue, Mar 7, 2017 at 7:12 PM Brad Fitzpatrick ***@***.***> wrote:
Closed #19451 <#19451>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#19451 (comment)>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AAD5VheTGcmBNKlswHnm7AX-zcibtTOZks5rjhykgaJpZM4MWQYx>
.
|
Perhaps. But any historical mistakes are locked-in at this point. |
OK. It seems that's the core issue, not that go/build can be used instead.
…On Tue, Mar 7, 2017 at 7:17 PM Brad Fitzpatrick ***@***.***> wrote:
Perhaps. But any historical mistakes are locked-in at this point.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#19451 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD5VtvAictuyJp5bPYW-N3svNz2Vnjzks5rjh3QgaJpZM4MWQYx>
.
|
Since Go v1.8 no longer requires setting GOPATH, does it make sense to add a
GOPATH() string
function to runtime, like there is for GOROOT?The text was updated successfully, but these errors were encountered: