module confusion

[K Richard Pixley]

I'm consistently finding modules confusing.

Here's today's confusion.  I think I've eliminated local environment settings but, once done, go get isn't working and I don't understand what needs to be changed.  What am I missing?

kpixley@editsb> type go
-bash: type: go: not found
kpixley@editsb> PATH=$PATH:${HOME}/go/bin ; export PATH

kpixley@editsb> type go
go is hashed (/homes/kpixley/go/bin/go)
kpixley@editsb> go version
go version go1.15 linux/amd64
kpixley@editsb> go get -u github.com/mna/pigeon
package github.com/mna/pigeon: cannot download, $GOPATH must not be set to $GOROOT. For more details see: 'go help gopath'
kpixley@editsb> ls .config/go
ls: cannot access '.config/go': No such file or directory
kpixley@editsb> ls /usr/local/go/bin
ls: cannot access '/usr/local/go/bin': No such file or directory
kpixley@editsb> echo $GOPATH

kpixley@editsb> echo $GOROOT

kpixley@editsb> go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/homes/kpixley/.cache/go-build"
GOENV="/homes/kpixley/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/homes/kpixley/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/homes/kpixley/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/homes/kpixley/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/homes/kpixley/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build515552229=/tmp/go-build -gno-record-gcc-switches"

[Jan Mercl]

On Fri, Aug 14, 2020 at 8:03 PM 'K Richard Pixley' via golang-nuts
<golan...@googlegroups.com> wrote:

> What am I missing?

> package github.com/mna/pigeon: cannot download, $GOPATH must not be set to $GOROOT. For more details see: 'go help gopath'

The above is the problem

> GOPATH="/homes/kpixley/go"

> GOROOT="/homes/kpixley/go"

The above is the proof.

Check where $GOPATH got set to the same value as $GOROOT (or vice
versa). Possibly in ~/.profile or ~/.bashrc. If not, check the output
of `go env` in a newly opened terminal window if the problem persists.
If not, it might have been set manually just in your current terminal.

[K Richard Pixley]

On 8/14/20 11:20, Jan Mercl wrote:
> [External Email. Be cautious of content]

Showed that in my output.  Neither are set.

[Carla Pfaff]

This has nothing to do with modules. You're still using the old GOPATH mode, because you're not in a directory with a go.mod file. GOPATH defaults to $HOME/go when it's not set (since 1.8), but that's where you chose to put your Go installation. This is not allowed. Either install Go to a different location, or set GOPATH to a different location.

[K Richard Pixley]

Isn't this the default location?  I just untarred the distribution...

The default gobin is ~/go/bin, no?  So I should be untarring in ~, no?

[Volker Dobler]

On Friday, 14 August 2020 20:39:37 UTC+2, K Richard Pixley wrote:

Isn't this the default location?  I just untarred the distribution...

No. There is a reason https://golang.org/doc/install#install

states to do  tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz

V.

[Carla Pfaff]

People and installers usually install Go in /usr/local/go on Unix-like systems.

~/go is the default GOPATH if not set, so ~/go/bin is where binaries installed via "go get" / "go install" land. But the Go distribution itself must not be under GOPATH.

[K Richard Pixley]

Thank you for the clarification.

I think that's exceeding confusing and needs much better documentation.

In particular, I think the installation instructions should suggest a
private install location if the obvious one isn't useful.

[Marvin Renich]

* Volker Dobler <dr.volke...@gmail.com> [200814 14:53]:

While (I believe) the majority of individuals (rather than sysadmins)
installing on Linux, MacOS, and FreeBSD will be the primary (essentially
sole) user on such systems, and will be able to use /usr/local (usually
requiring su or sudo or modifying permissions on /usr/local, which is
not mentioned in the above referenced instructions), this is not a
universal condition. Especially, students at universities using an
account on a university machine will generally not have access to
/usr/local. I think this is a significant enough use case to warrant a
mention in the installation instructions, e.g.

If you do not have access to /usr/local, or do not wish to install
there, you may install to another directory, such as $HOME/goroot.
The directory $HOME should not be used, as this would make $GOROOT the
same as the default $GOPATH ($HOME/go), which is not allowed.

Anything along these lines would help alleviate the confusion that the
OP had.

It also might be productive to mention that many (Linux?) distributions
(e.g. Debian, Fedora, RHEL) provide reasonably up-to-date packages for
Go, and that using the distribution's package manager may be easier,
provide better security support, and integrate better than manually
installing the official Go binary distribution.

...Marvin

[fge...@gmail.com]

On 8/15/20, Marvin Renich <mr...@renich.org> wrote:
> * Volker Dobler <dr.volke...@gmail.com> [200814 14:53]:
>> On Friday, 14 August 2020 20:39:37 UTC+2, K Richard Pixley wrote:
>> > Isn't this the default location? I just untarred the distribution...
>>
>> No. There is a reason https://golang.org/doc/install#install
>> states to do tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
>

....

> It also might be productive to mention that many (Linux?) distributions
> (e.g. Debian, Fedora, RHEL) provide reasonably up-to-date packages for
> Go, and that using the distribution's package manager may be easier,
> provide better security support, and integrate better than manually
> installing the official Go binary distribution.

Could you please give an example to "better security support" in a
distribution's package manager?

[Marvin Renich]

* fge...@gmail.com <fge...@gmail.com> [200815 03:44]:

The user can let the package manager automatically update packages with
security fixes (at least in Debian) so the user doesn't have to stay on
top of when a security update is available and manually reinstall the
updated version of Go. (Think of trying to do this individually for
every piece of software installed on your system.)

Perhaps "simpler" would have been a better word than "better". One of
the big reasons to use packages from a distribution rather than
installing each one from source or from upstream's binary packages is to
simplify system maintenance.

...Marvin

[fge...@gmail.com]

Let's just agree that the automated update scheme can be simple to some and confusing to others.

Iirc that's one of the reasons why different package managers aren't mentioned or supported.

If you search the list for earlier messages about the os provided package management from a couple of years ago, you'll maybe find different reasons as well.

[K Richard Pixley]

On 8/15/20 00:43, fge...@gmail.com wrote:
> On 8/15/20, Marvin Renich <mr...@renich.org> wrote:
>> * Volker Dobler <dr.volke...@gmail.com> [200814 14:53]:
>>> On Friday, 14 August 2020 20:39:37 UTC+2, K Richard Pixley wrote:
>>>> Isn't this the default location? I just untarred the distribution...

>>> No. There is a reason https://urldefense.com/v3/__https://golang.org/doc/install*install__;Iw!!NEt6yMaO-gk!R3z5eGP7tSVHh9dkw1eEv-l-WAko3RdxhuxICWySuRetk6bW0W3c9v5JhOxueCU2Ww$

>>> states to do tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
> ....
>> It also might be productive to mention that many (Linux?) distributions
>> (e.g. Debian, Fedora, RHEL) provide reasonably up-to-date packages for
>> Go, and that using the distribution's package manager may be easier,
>> provide better security support, and integrate better than manually
>> installing the official Go binary distribution.
> Could you please give an example to "better security support" in a
> distribution's package manager?

Part of the job of a distribution is integration.  Who owns which files,
where they are stored, and who has access to them are all under the
auspices of integration.  Go itself can't really be expected to manage
all of those details for every single distribution that might ever
exist.  But the local package manager can, and typically does both own
and manage those details.

[fge...@gmail.com]

On 8/17/20, 'K Richard Pixley' via golang-nuts

Oh but yes, I expect that the current Go installation scheme is
expected to manage all those details (a user's private namespace), so
it shall be a viable alternative for quite a long time.
(Although my imagination is limited, at the moment I can't imagine a
change where the all too frequent global namespace pollution of
operating system packages, which as I understand you can call
management if you like, would mess up the private namespace of a user
that much. At least for the mainstream desktop and server operating
systems.)

[K Richard Pixley]

I think you're missing my point.  Let me try again.

If the standard location for the go compiler is /usr/local/go/bin and
anyone with access to that file system can, at will, install a new
compiler, then the other users are at their mercy.  Policies for who can
or can't install a new /usr/local/go/bin/go are up to the distribution
and generally handled by the distribution's packaging and integration
policies.

Eg, is it owned by root?  By bin?  By "golang"?  What group?  Is
/usr/local/go/bin a local file system?  Shared, perhaps by NFS or ceph? 
Or duplicated and distributed read-only as a cloud based filesystem on a
cloud-based-block-device?

These are all decisions made by system admins in concert with the
distribution they're using.  The distributors of golang proper can't
really be held responsible for each and every possible local
convention.  But the local sysadmins, (in concert with their
distribution), certainly can.

Anyway, this is a level of security that cannot reasonably be expected
of the golang team but can, and typically is, expected from
distributions.  I believe that is an answer to the question that was asked.