package <whatever> is not in GOROOT

10,560 views
Skip to first unread message

rob

unread,
Apr 5, 2021, 8:13:14 PM4/5/21
to golang-nuts
I'm still struggling w/ modules to get my code to compile.  This example
is on Win10 using go 1.16.3

~/go/src/rpng/rpng.go

~/go/src/tokenize/tokenize.go

~/go/src/hpcalc2/hpcalc2.go

I'm logged into ~/go/src and I type this, like I used to do in the "old"
days:

    go install rpng

Now I get this error: package rpng is not in GOROOT (\Program
Files\Go\src\rpng)

I don't understand how to clear the error to get my code to compile.  In
each of my directories in ~/go/src, I've run

    go mod init <module name>

Yet the compiler cannot find other bits of code that I've written.

I am able to compile packages/modules in which I do not import anything
else that I've written.

Any help would be appreciated.

Carla Pfaff

unread,
Apr 6, 2021, 6:40:11 AM4/6/21
to golang-nuts
On Tuesday, 6 April 2021 at 02:13:14 UTC+2 rob wrote:
I'm still struggling w/ modules to get my code to compile.  This example
is on Win10 using go 1.16.3

~/go/src/rpng/rpng.go
~/go/src/tokenize/tokenize.go
~/go/src/hpcalc2/hpcalc2.go


Put them in a directory, e.g. "rob". This can be anywhere, it doesn't have to be under "~/go/src":

  rob/rpng/rpng.go 
  rob/tokenize/tokenize.go 
  rob/hpcalc2/hpcalc2.go

 In each of my directories in ~/go/src, I've run

    go mod init <module name>

Delete these go.mod/go.sum files that you created in the sub-directories.

Then go in the "rob" directory and init the module "rob":

  cd rob
  go mod init rob

Result:

  rob/go.mod
  rob/go.sum
  rob/rpng/rpng.go 
  rob/tokenize/tokenize.go 
  rob/hpcalc2/hpcalc2.go

Now always import the packages with the module prefix "rob/":

  import "rob/rpng"
  import "rob/tokenize"
  ...

rob

unread,
Apr 6, 2021, 7:39:30 PM4/6/21
to golang-nuts
> This example is on Win10 using go 1.16.3

Now I've created a directory tree outside of ~/go/src.  I'm using ~ to
mean %userprofile%, as this is win10

~/gcode/rpng/rpng.go

~/gcode/tokenize/tokenize.go

~/gcode/hpcalc2/hpcalc2.go

And I updated my import statement to be "gcode/hpcalc2", etc.

Now I can use

     go run gcode/rpng/rpng.go

And I set GOBIN=c:\Users\rob\gcode

    go install gcode/rpng/rpng.go

and it installs to GOBIN.

At least it's working for me mostly the way it was before.  I just had
to abandon my ~/go directory

Thanks for answering

Rob

wagner riffel

unread,
Apr 7, 2021, 10:25:07 AM4/7/21
to rob, golang-nuts
Hi Rob, it's good that you got it working, but I feel you're struggling
with modules inferred from your past emails due a confusion between a
module namespace and the file system, your package import paths and go
commands are relative to a *module* and not a directory, your current
module namespace is detected similarly as a git repository is, that is,
traverse current working directory up until a go.mod is found (or .git
for git), and then if a module is found, you import packages or use the
go commands in the format of *module_name*/folder/..., not file system
paths, what go cares as a namespace is the module name, not
absolute/relative file system paths.

For example, suppose our current working directory is "~/gcode/" and it
has a go.mod named¹ "foo", note that the folder is named gcode but the
module is "foo", you would install the "rpng" package inside this
module namespace "foo" with:
$ go install foo/rpng

you can refer file path relatives alike as well:
$ go install ./rpng # OK
$ go install rpng # invalid, would fail with the same not found message

you can think as dot expanding to "foo", not the file system gcode
folder, to make clear that it's not about file system paths, changing
our current working directory to "tokenize", we still can mention "rpng"
relative to the module, not the file system:
$ cd ~/gcode/tokenize
$ go install foo/rpng
$ go install ../rpng # valid as well

I'm not sure if this helps you or causes even more confusions, if so
sorry.

BR.

--wagner

[1] the module name is usually a domain, but not necessarily, refer to
https://pkg.go.dev/golang.org/x/mod/module#CheckPath for detailed
description.

rob

unread,
Apr 7, 2021, 10:46:18 AM4/7/21
to wagner riffel, golang-nuts
It does help me.

Thanks

--
rob
drro...@fastmail.com

rob

unread,
Apr 7, 2021, 8:11:50 PM4/7/21
to wagner riffel, golang-nuts
Yes, you are absolutely correct that I've been struggling w/ modules.

Would it be a bad idea to use my ~go/src as a module?

  cd ~/go/src

  go mod init src

  go mod tidy     --> do I need this?

And then I would have to edit my import statements slightly to include
the module reference.

--rob solomon

Carla Pfaff

unread,
Apr 7, 2021, 11:56:04 PM4/7/21
to golang-nuts
On Thursday, 8 April 2021 at 02:11:50 UTC+2 rob wrote:
Yes, you are absolutely correct that I've been struggling w/ modules.

Would it be a bad idea to use my ~go/src as a module?

  cd ~/go/src

  go mod init src

  go mod tidy     --> do I need this?

And then I would have to edit my import statements slightly to include
the module reference.

--rob solomon

That's basically what I suggested to you in my response. Only, instead of  "~/go/src" I called it "rob".

wagner riffel

unread,
Apr 9, 2021, 11:02:22 AM4/9/21
to rob, r...@drrob1.com, golang-nuts
On Wed, 7 Apr 2021 20:11:22 -0400
rob <drro...@fastmail.com> wrote:

> Would it be a bad idea to use my ~go/src as a module?
>

I don't think so, I do have one global module like this for my own toys
and throwaways programs. Yes, it would need to adjust your import paths
according to the module, when I migrated to module it was easier
because everything was inside the same global folder, so I just needed
to init a module with that name.

>   go mod tidy     --> do I need this?
>

go mod tidy adds missing modules in go.mod/go.sum that you're importing
from go sources, and removes dangling ones (not found in your go
sources but in your go.mod/go.sum), it's wise to run it if you're
initializing a module from an existing code base.

--wagner

rob

unread,
Apr 9, 2021, 11:09:48 AM4/9/21
to wagner riffel, r...@drrob1.com, golang-nuts
Thanks.

If only the docs would make that clear.

My experience with reading them is: clear only if previously known.
Much frustration about modules could have been avoided by more clearly written documentation

So it goes




--
rob
drro...@fastmail.com
Reply all
Reply to author
Forward
0 new messages