golang paths
156 views
Skip to first unread message
Dumitru Ungureanu
Dec 7, 2020, 6:06:29 PM12/7/20
to golang-nuts
Hi.
I'm currently using this directory tree for golang. Is there something I'm not taking into consideration, maybe? Thanks.
├─ go
│ ├─ bin (GOBIN, where install command deploys binaries)
│ ├─ cache (GOCACHE, where cached builds await reuse)
│ ├─ modules
│ ├─ path (GOPATH, first workspace, where downloaded packages are)
│ └─ root (GOROOT, golang installation goes here)
│ env (GOENV, the golang config file)
fge...@gmail.com
Dec 8, 2020, 9:45:06 AM12/8/20
to Dumitru Ungureanu, golang-nuts
On 12/7/20, Dumitru Ungureanu <itmi...@gmail.com> wrote:
...
What do you mean when you write "golang"?
Why is https://golang.org/doc/install not good enough for the go compiler?
...
> I'm currently using this directory tree for golang.
...
What do you mean when you write "golang"?
Why is https://golang.org/doc/install not good enough for the go compiler?
Dumitru Ungureanu
Dec 8, 2020, 11:16:17 AM12/8/20
to golang-nuts
Paths in symmetry with the environmental variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin. GOCACHE is go/cache, GOENV is go/env. Bonus points: modules in go/modules.
fge...@gmail.com
Dec 8, 2020, 11:28:50 AM12/8/20
to Dumitru Ungureanu, golang-nuts
On 12/8/20, Dumitru Ungureanu <itmi...@gmail.com> wrote:
> Paths in symmetry with the environmental
> variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin. GOCACHE is
> go/cache, GOENV is go/env.
> Bonus points: modules in go/modules.
Why do you need to manage them explicitly? When do you need to look at
> Paths in symmetry with the environmental
> variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin. GOCACHE is
> go/cache, GOENV is go/env.
> Bonus points: modules in go/modules.
GOROOT, GOBIN, GOCACHE or GOENV?
(I've never set or checked GOROOT, GOBIN, GOCACHE or GOENV explicitly.
After modules became the default, I've never set GOPATH either.)
>
> On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi wrote:
>
>> On 12/7/20, Dumitru Ungureanu <itmi...@gmail.com> wrote:
>> ...
>> > I'm currently using this directory tree for golang.
>> ...
>> What do you mean when you write "golang"?
>>
>> Why is https://golang.org/doc/install not good enough for the go
>> compiler?
>>
>
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/f5c636d8-97e3-4fc1-a28f-d5cc93a0fa52n%40googlegroups.com.
>
Dumitru Ungureanu
Dec 8, 2020, 11:38:10 AM12/8/20
to golang-nuts
I don't use an installer. I set GOROOT/bin manually. And the rest follows. Easy to remember, nothing to forget.
fge...@gmail.com
Dec 8, 2020, 3:47:27 PM12/8/20
to Dumitru Ungureanu, golang-nuts
There is no requirement to manage these variables or to know about them, even if you don't use the installer.
The installed go compiler is really just a trivial tree.
I never use the installer and I've never needed to check on those environment variables.
(The installation documentation is short and complete, maybe you should check it out again.)
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/86ab9747-9c2c-4f91-9980-6d00b3a3af13n%40googlegroups.com.
Dumitru Ungureanu
Dec 9, 2020, 12:10:42 AM12/9/20
to golang-nuts
Yes, there is no requirement to manage the envvars. I personally believe there is a requirement to know about them, though.
I read the installation doc, I think there's a hang up on your part on this one.
The default go tree is scattered different places, beside the obvious trivial tree you're mentioning.
I'm arranging all the paths in a single place and I harmonize the paths with the envvars.
Maybe you're missing the whole point I'm making in this blog post? https://mitflit.ro/blog/golang-paths-of-mitflit/
fge...@gmail.com
Dec 9, 2020, 2:02:46 AM12/9/20
to Dumitru Ungureanu, golang-nuts
To clarify the go compiler toolchain is a trivial tree. Compared to
most other mainstream languages and compilers, it's not scattered to
different subtrees. I believe quite some effort went into that to stay
that way.
When using the go compiler toolchain some directories are used for
caching compiler artifacts. (You could easily delete all of these
files between compiling sessions, you'll still be able to compile
everything again. Though only a very space constrained environment
would require such a peculiar workflow.)
If you are a go programmer the subtrees you set explicitly are 100%
managed by the toolchain, there is no _need_ to ever look at them.
Please note, that if you set them explicitly and with that you
inadvertently mix and match different versions of go toolchain
binaries and cached artifacts you'll most probably run into issues you
don't want to have.
Sure the environment variables can be set differently, if you have
special requirements (maybe you don't have enough space on the same
device). Sorry I wasn't clear: I tried to ask for these special
requirements.
To rephrase and clarify my original question: besides "Paths in
symmetry with the environmental variables" why is it valuable to
rearrange the subtrees for your use case? What are your
requirements/issues you came up with a solution for?
To help with your original question, assuming your only goal is to
manage all subtrees exposed by environment variables "go env" shows at
least 3 more trees you might want to set (GOMODCACHE, GOTOOLDIR,
GOTMPDIR.)
>>> <https://groups.google.com/d/msgid/golang-nuts/86ab9747-9c2c-4f91-9980-6d00b3a3af13n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>
most other mainstream languages and compilers, it's not scattered to
different subtrees. I believe quite some effort went into that to stay
that way.
When using the go compiler toolchain some directories are used for
caching compiler artifacts. (You could easily delete all of these
files between compiling sessions, you'll still be able to compile
everything again. Though only a very space constrained environment
would require such a peculiar workflow.)
If you are a go programmer the subtrees you set explicitly are 100%
managed by the toolchain, there is no _need_ to ever look at them.
Please note, that if you set them explicitly and with that you
inadvertently mix and match different versions of go toolchain
binaries and cached artifacts you'll most probably run into issues you
don't want to have.
Sure the environment variables can be set differently, if you have
special requirements (maybe you don't have enough space on the same
device). Sorry I wasn't clear: I tried to ask for these special
requirements.
To rephrase and clarify my original question: besides "Paths in
symmetry with the environmental variables" why is it valuable to
rearrange the subtrees for your use case? What are your
requirements/issues you came up with a solution for?
To help with your original question, assuming your only goal is to
manage all subtrees exposed by environment variables "go env" shows at
least 3 more trees you might want to set (GOMODCACHE, GOTOOLDIR,
GOTMPDIR.)
>>> .
>>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c0ed7490-800b-424e-834a-4f928be2a52en%40googlegroups.com.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit
>
Dumitru Ungureanu
Dec 9, 2020, 2:42:10 AM12/9/20
to golang-nuts
I decided to place them all in one place for containment.
I used the names from envvars to get a simple answer to a simple question: where is GOROOT?, in go/root.
GOMODCACHE picks up GOPATH.
GOTOOLDIR picks up GOROOT.
GOTMPDIR defaults to system's tmp dir, I'm fine with that.
fge...@gmail.com
Dec 9, 2020, 3:04:48 AM12/9/20
to Dumitru Ungureanu, golang-nuts
On 12/9/20, Dumitru Ungureanu <itmi...@gmail.com> wrote:
> I decided to place them all in one place for containment.
Thanks! (Though I believe we can agree to disagree on the value of
> I decided to place them all in one place for containment.
this version of containment.)
> I used the names from envvars to get a simple answer to a simple question:
Interesting! I'm curious, what is the problem, when you need a
different answer other than "go env|grep GOROOT" ?
Dumitru Ungureanu
Dec 9, 2020, 3:13:15 AM12/9/20
to golang-nuts
Yes, you can safely assume we can agree to disagree on the value of my version for containment, no problem here :)
My problem starts with the containment of the golang dev space for the user. Going from here, what dir names should I use? So I thought that using a dir tree based on envvars names should keep the confusion to a minimum.
fge...@gmail.com
Dec 9, 2020, 3:47:17 AM12/9/20
to Dumitru Ungureanu, golang-nuts
Sorry, I've lost it at "golang dev space", but I guess there could be
an explicit definition to that new phrase. (Though if that definition
is not used anywhere else, I can't see any value in that either.)
The directories exposed by the environment variables are not there to
be explicitly managed when doing go programming.
Most probably it's my lack of imagination, but after 11 emails I still
don't see the case where setting these variables has more value than
cost+risk.
That means I can't help with "Is there something I'm not taking into
consideration, maybe?". Best of luck!
cheers
On 12/9/20, Dumitru Ungureanu <itmi...@gmail.com> wrote:
> Yes, you can safely assume we can agree to disagree on the value of my
> version for containment, no problem here :)
>
> My problem starts with the containment of the golang dev space for the
> user. Going from here, what dir names should I use? So I thought that using
>
> a dir tree based on envvars names should keep the confusion to a minimum.
>
> On Wednesday, December 9, 2020 at 10:04:48 AM UTC+2 Gergely Födémesi wrote:
>
>> On 12/9/20, Dumitru Ungureanu <itmi...@gmail.com> wrote:
>> > I decided to place them all in one place for containment.
>> Thanks! (Though I believe we can agree to disagree on the value of
>> this version of containment.)
>>
>> > I used the names from envvars to get a simple answer to a simple
>> question:
>> > *where is GOROOT?*, *in go/root*.
>> Interesting! I'm curious, what is the problem, when you need a
>> different answer other than "go env|grep GOROOT" ?
>>
>
>
an explicit definition to that new phrase. (Though if that definition
is not used anywhere else, I can't see any value in that either.)
The directories exposed by the environment variables are not there to
be explicitly managed when doing go programming.
Most probably it's my lack of imagination, but after 11 emails I still
don't see the case where setting these variables has more value than
cost+risk.
That means I can't help with "Is there something I'm not taking into
consideration, maybe?". Best of luck!
cheers
On 12/9/20, Dumitru Ungureanu <itmi...@gmail.com> wrote:
> Yes, you can safely assume we can agree to disagree on the value of my
> version for containment, no problem here :)
>
> My problem starts with the containment of the golang dev space for the
> user. Going from here, what dir names should I use? So I thought that using
>
> a dir tree based on envvars names should keep the confusion to a minimum.
>
> On Wednesday, December 9, 2020 at 10:04:48 AM UTC+2 Gergely Födémesi wrote:
>
>> On 12/9/20, Dumitru Ungureanu <itmi...@gmail.com> wrote:
>> > I decided to place them all in one place for containment.
>> Thanks! (Though I believe we can agree to disagree on the value of
>> this version of containment.)
>>
>> > I used the names from envvars to get a simple answer to a simple
>> question:
>> > *where is GOROOT?*, *in go/root*.
>> Interesting! I'm curious, what is the problem, when you need a
>> different answer other than "go env|grep GOROOT" ?
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b272eef9-f0d0-40d1-8a15-f92ca89e976bn%40googlegroups.com.
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit
>
Dumitru Ungureanu
Dec 9, 2020, 4:04:29 AM12/9/20
to golang-nuts
The centralized golang tree structure I described and use is not a case of going against golang defaults. It's a case of amending the default paths for the purpose of bringing it all in one place, all golang related, that is. On every machine I develop with golang, my first blind thought is to place the binary release it in the `go` directory for my user, which will become GOROOT. But this is the default GOPATH, I remember instantly. And there are also the paths for cache and the installed binaries to account for, having default paths placed in various locations. Hunting them down when needed seemed counterproductive. The `env` files provided a way to customize so I used it. I used in a way to describe the paths by using the names they are assigned as envvars. Easy to remember, nothing to forget. Management made easier.
Reply all
Reply to author
Forward
0 new messages