where is GOROOT set?

[pat2...@gmail.com]

I'm missing something fundamental.
I have set GOROOT to my current directory, which contains my go source files

but I can't test a trivial program

treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program Files\Go\src\treesort)

It looks like the value of the GOROOT variable is set to a different value
inside go itself, and not to the value that the shell sees.

(the program is treesort from the Kernigan and Donovan book)

// Copyright © 2016 Alan A. A. Donovan & Brian W. Kernighan.
// License: https://creativecommons.org/licenses/by-nc-sa/4.0/
// See page 101.

Sorry for the long PWD, but I'm trying to keep these trivial programs in github
and the path seems to be required.

pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$ echo $GOROOT
/home/pfarrell/whome/sandbox/gows/src/github.com/pfarrell51/cmd

pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$ go test treesort_test.go
# command-line-arguments
treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program Files\Go\src\treesort)
FAIL    command-line-arguments [setup failed]
FAIL

pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$ echo $GOROOT
/home/pfarrell/whome/sandbox/gows/src/github.com/pfarrell51/cmd

pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$ printenv GOROOT
/home/pfarrell/whome/sandbox/gows/src/github.com/pfarrell51/cmd

This has to be something trivial that I'm doing wrong

Thanks

[Ian Lance Taylor]

On Thu, Nov 17, 2022 at 8:59 PM pat2...@gmail.com <pat2...@gmail.com> wrote:
>
> I'm missing something fundamental.
> I have set GOROOT to my current directory, which contains my go source files
> but I can't test a trivial program

In general you should never set GOROOT. It's a special purpose hook
that is almost never needed.

What happens if you don't set it in the environment?

Ian

[pat2...@gmail.com]

Here I clear it, same result:

pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$ export GOROOT=
pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$ printenv GOROOT

pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$ go test treesort_test.go
# command-line-arguments
treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program Files\Go\src\treesort)
FAIL    command-line-arguments [setup failed]
FAIL

Interesting: even though I cleared it to bash, it still shows up as being set in go

pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$ go env
set GO111MODULE=
set GOENV=C:\Users\pfarrell\AppData\Roaming\go\env
set GOPATH=C:\Users\pfarrell\go
set GOROOT=C:\Program Files\Go

[Dan Kortschak]

On Thu, 2022-11-17 at 21:20 -0800, pat2...@gmail.com wrote:
> pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$
> go test treesort_test.go

This is not how go test should be invoked. You just need to do go test
in the directory that you package lives in.

See https://pkg.go.dev/cmd/go#hdr-Test_packages

[pat2...@gmail.com]

OK, all the source files are in the same directory

I did the go mod

it didn't work as you typed, but I got it to work

I'm pretty sure I don't understand packages and modules.

I really an not using any of that, I just have a half dozen go files some with main() and

some with tests.

I am now getting a different error message:

$ go test
found packages main (csvtsd.go) and quaternion (quaternion.go) in C:\Users\pfarrell\sandbox\gows\src\github.com\pfarrell51\cmd
pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$

after doing this:

$ go mod init
go: cannot determine module path for source directory C:\Users\pfarrell\sandbox\gows (outside GOPATH, module path must be specified)

Example usage:
        'go mod init example.com/m' to initialize a v0 or v1 module
        'go mod init example.com/m/v2' to initialize a v2 module

Run 'go help mod init' for more information.

$ go mod init src/github.com/pfarrell51/cmd/
go: malformed module path "src/github.com/pfarrell51/cmd/": trailing slash

$ go mod init src/github.com/pfarrell51/cmd
go: creating new go.mod: module src/github.com/pfarrell51/cmd
go: to add module requirements and sums:
        go mod tidy
pfarrell@Alien15:~/whome/sandbox/gows$ go mod tidy

$ go test
found packages main (csvtsd.go) and quaternion (quaternion.go) in C:\Users\pfarrell\sandbox\gows\src\github.com\pfarrell51\cmd

It seems to be missing two test.go files in the directory:

$ ls *test.go
csvtsd_test.go  goprorename_test.go  quaternion_test.go  treesort_test.go

There are really no need for packages or modules for these programs.

They are just simple go programs that work like perl or python programs, designed to take work with pipes

Some have package names because the source I pulled from random places had a package line.

[Ian Lance Taylor]

On Fri, Nov 18, 2022 at 6:19 AM pat2...@gmail.com <pat2...@gmail.com> wrote:
>
> There are really no need for packages or modules for these programs.
> They are just simple go programs that work like perl or python programs, designed to take work with pipes
> Some have package names because the source I pulled from random places had a package line.

It is a little complicated to set up initially. You do have to run
"go mod init PACKAGEPATH". You do have to put different packages in
different directories. We believe that although it is a little harder
to get started than some scripting languages, it pays off quickly in
the ease and security of importing and using other people's packages.

Ian

[Brian Candler]

> They are just simple go programs that work like perl or python programs, designed to take work with pipes

You still should have a go.mod.  Even if you don't intend to publish your code anywhere, you give it a module name - anything will do as long as it meets the syntax requirements.

See example here: https://groups.google.com/g/golang-nuts/c/SUWXeLjuWY0/m/fg9nhD47DwAJ

Then you need "go test ." not "go test" (notice the dot)

> There are really no need for packages or modules for these programs.

These days, anything other than a trivial hello-world type program should have a go.mod.  As soon as you start importing any third party libraries you most definitely need it.

You will always have a package - at least package "main".

If you need to split your code into other packages, you can put those in subdirectories.  Those don't need their own go.mod files.  The path for each package is the path from the outer go.mod file, concatenated with the subdirectory.

[pat2...@gmail.com]

thanks

On Friday, November 18, 2022 at 1:10:40 PM UTC-5 Brian Candler wrote:

You still should have a go.mod.  Even if you don't intend to publish your code anywhere, you give it a module name - anything will do as long as it meets the syntax requirements.

OK, I can have a go.mod

But don''t I need to have a "package main" in order to get an executable?

If you need to split your code into other packages, you can put those in subdirectories.  Those don't need their own go.mod files.  The path for each package is the path from the outer go.mod file, concatenated with the subdirectory.

Sure, once there is more than 25 lines of source code, subdirectories make sense.

Do I really need to have the source code deeply burried in names that tie it all to my github repository?

I'm using
       ~/sandbox/gows/src/github.com/pfarrell51/cmd

 

because "gows" is "go work space" with src code

and github/pfarrell51/cmd
is where I've kept all my shell/cmd program source.

Thanks

Pat

[Brian Candler]

On Saturday, 19 November 2022 at 02:50:18 UTC pat2...@gmail.com wrote:

On Friday, November 18, 2022 at 1:10:40 PM UTC-5 Brian Candler wrote:

You still should have a go.mod.  Even if you don't intend to publish your code anywhere, you give it a module name - anything will do as long as it meets the syntax requirements.

OK, I can have a go.mod

But don''t I need to have a "package main" in order to get an executable?

Correct.  Your .go source file(s), which together build a single executable, will all have "package main" as the first line, and all sit in the same directory.

Starting point, with a single file:

mkdir hello

cd hello

go mod init example.com/hello    # this creates "go.mod"

vi hello.go   # create your program here

go run .

where hello.go contains

package main

import "fmt"

func main() {

    fmt.Println("Hello, world!")

}

You could then split this into two files:

-- hello.go --

package main

func main() {

    sayHello()

}

-- speaker.go --

package main

import "fmt"

func sayHello() {

    fmt.Println("Hello, world!")

}

In general, all source files in the same directory are part of the same package, and must have the same 'package' declaration. The exception is if you choose to put your test functions in a different package (if you want them only to be able to access the public API of your package)

You can have multiple .go source files, in the same directory, all part of the same package.  Functions in each file can use functions and data from any other file, without having to refer to them explicitly.

Think of "a directory of files" as a single compilation unit.  It's pretty much the same as having one big source file, except that each individual source file still has to have its own 'import' statements.

 

If you need to split your code into other packages, you can put those in subdirectories.  Those don't need their own go.mod files.  The path for each package is the path from the outer go.mod file, concatenated with the subdirectory.

Sure, once there is more than 25 lines of source code, subdirectories make sense.

But you don't need to split into multiple subdirectories at this point: only multiple files in the same directory.  (Unless you're talking about separate executables, in which case, yes they need to be in separate subdirectories).

 

Do I really need to have the source code deeply burried in names that tie it all to my github repository?

I'm not sure what you mean by that.  All the source files in the same package (in the same directory) don't need to import each other at all, so they do not reference each other by module name.

The module name is used when you need to import code from somewhere else.  If you choose a module name that links to your github repository, then other people will be able to import your module using that name, and the code will be fetched and built automatically.

 

I'm using
       ~/sandbox/gows/src/github.com/pfarrell51/cmd

 

because "gows" is "go work space" with src code

Be careful with your terminology here: there is a specific feature called "go workspaces", but this has only been recently added and is an advanced topic (for working on very large projects) and you should ignore it for now.

If you just mean "this is where I put my source files", then that's fine; but all the files in one directory must be part of the same package, and thus part of the same application (i.e. you build them all as one executable).

Incidentally, there is no need to have github.com in the directory path on your local filesystem.  You could just use

~/projects/cmd

What if you are building multiple executables?  You put them into separate subdirectories.  If you're treating this all as one module:

~/projects/cmd   contains  go.mod (and nothing else)

~/projects/cmd/foo  contains *.go files, all for package main, which build the "foo" executable

~/projects/cmd/bar  contains *.go files, all for package main, which build the "bar" executable

You can then if you wish publish this whole lot in a single repo as github.com/pfarrell51/cmd - or not, as you choose.  If not, then the name that you choose for your module doesn't matter.

This repo can also contain library code which is shared between these executables - this would be in separate packages, and would have to be explicitly imported by the executables.

Option 1: the top-level ~/projects/cmd can contain *.go files.  These might all have "package cmd" and can be imported using your bare module path, e.g. github.com/pfarrell51/cmd

Option 2: you can put library code in subdirectories too, e.g. ~/projects/cmd/utils/ can contain *.go files, with "package utils", and are imported using github.com/pfarrell51/cmd/utils.  There is a special subdirectory "internal" which can be used for code which is shared between your own executables but you *don't* want to be available to anyone else importing from your repo.

So your foo and bar executables might look like this:

package main

import "github.com/pfarrell51/cmd"

func main() {

    cmd.SayHello()

}

If the "foo" and "bar" executables are completely independent and don't share any code, then I would publish them as separate repos, each with their own go.mod.

Note that import "github.com/pfarrell51/cmd" doesn't mean "fetch this code from github".  It just refers to the module's name.  By walking up the parent directories and finding go.mod, Go realises that the named module you are referring to is already on your filesystem as part of your project, and uses that directly.  This is why it works to use random module names like example.com/test

Regards,

Brian.

P.S. I don't want to confuse you any further, but you should be aware that package name that you use (for a bundle of sources files in a directory) doesn't necessarily have to be the same as the subdirectory they are contained within - but if they don't match it can get confusing.  For example:

-- go.mod --
module example.com/myprog

go 1.16

-- start.go --
package main

import (
    "example.com/myprog/foo"
    "fmt"
)

func main() {
    fmt.Println(wibble.Bibble())
}

-- foo/misc.go --
package wibble

func Bibble() string {
    return "baa"
}

The subdirectory "foo" contains a package "wibble".  So in the main program (start.go), there is import "example.com/myprog/foo", but it actually makes a package called "wibble" available.

The solution here is to name the imported package explicitly, e.g.

import (
    wibble "example.com/myprog/foo"

)

This says "regardless of what the imported package calls itself, I want to refer to it as "wibble" within this package"

[pat2...@gmail.com]

Thanks again

Bit of background, I've been playing with go on and off for five or six years. I have decades of experience in 
various systems programming languages, including things like TOPS-10 macro, c, bliss, etc. Go is very

attractive to my systems-internals side. 
About five years ago I started writing some go programs that were typical shell programs that

two decades ago I would have written in perl. Thus the "cmd" directory since in the windows world at the time,
you ran in the 'cmd shell'

I've recently got the bug again to write some go.

Over the years, go has changed, and example programs on the web have changed.

So what I am copying from has various vintages and has code from many sources, some of which may be very obsolete.

On Saturday, November 19, 2022 at 3:15:08 AM UTC-5 Brian Candler wrote:

But you don't need to split into multiple subdirectories at this point: only multiple files in the same directory.  (Unless you're talking about separate executables, in which case, yes they need to be in separate subdirectories).

Yes, I was specifically talking about creating separate executables.

So one subdirectory for each separate executable it shall be.

  

Do I really need to have the source code deeply burried in names that tie it all to my github repository?

I'm not sure what you mean by that.  All the source files in the same package (in the same directory) don't need to import each other at all, so they do not reference each other by module name.

I am in the habit of sharing all of my code, with github being the sharing technique of choice over the past decade or so.

 

The module name is used when you need to import code from somewhere else.  If you choose a module name that links to your github repository, then other people will be able to import your module using that name, and the code will be fetched and built automatically.

That is what I want to do. I want folks to be able to use my code if they want.
But the naming of the subdirectories with the full path to my github reposities is fairly ugly and cumbersome.

 

  

I'm using
       ~/sandbox/gows/src/github.com/pfarrell51/cmd 

because "gows" is "go work space" with src code

Be careful with your terminology here: there is a specific feature called "go workspaces", but this has only been recently added and is an advanced topic (for working on very large projects) and you should ignore it for now.

Somewhere along the line, some example years ago talked about a go workspace, so I invented the gows subdirectory.

 

Incidentally, there is no need to have github.com in the directory path on your local filesystem.  You could just use

~/projects/cmd

Doesn't this contradict putting the github path in the name for easy automatic use?
Or am I confusing two issues?

If the "foo" and "bar" executables are completely independent and don't share any code, then I would publish them as separate repos, each with their own go.mod.

So far, they have all been completely independent, but that is mostly because in go, I'm a rookie and nothing I've written is very substantial.

 

Note that import "github.com/pfarrell51/cmd" doesn't mean "fetch this code from github".  It just refers to the module's name.  By walking up the parent directories and finding go.mod, Go realises that the named module you are referring to is already on your filesystem as part of your project, and uses that directly.  This is why it works to use random module names like example.com/test

I'm not following this, I thought that was exactly why I put in the "github.com/pfarrell51/<modulename>"

in the source directory structure, and therefor in the github 

https://github.com/pfarrell51/gows repository

so if someone wanted to use my PID code or my quaternion code, it would be easy and automatic

Thanks

Pat

[Brian Candler]

On Monday, 21 November 2022 at 04:11:26 UTC pat2...@gmail.com wrote:

Incidentally, there is no need to have github.com in the directory path on your local filesystem.  You could just use

~/projects/cmd

Doesn't this contradict putting the github path in the name for easy automatic use?
Or am I confusing two issues?

You are confusing two issues, although this probably comes from your experience with go before GOMODULES, where you did have an automatically-created hierarchy under $GOPATH/src.  I came to go just as the transition was taking place.

There are two separate concepts now:

(1) The *name* of your module.  This conventionally looks like github.com/pfarrell51/cmd to allow automatic fetching from github (but doesn't have to).

(2) The *directory* on your local filesystem where your code lives.  This can be anywhere and does not have to look anything like your module name.  This is because the "go.mod" file provides the binding between the module name and filesystem location.

- if the current directory contains go.mod, then go.mod names the package in this directory

- if the current directory doesn't contain go.mod, then go walks up the filesystem to find one.  Then the name of the package in the current directory is the name of the module in go.mod, concatenated with the subdirectory path needed to get from go.mod's directory to this one.

That is: if ~/projects/misc contains a go.mod with name example.com/test, then ~/project/misc/foo has name example.com/test/foo implicitly (as long as it doesn't have its own go.mod file).

 

Note that import "github.com/pfarrell51/cmd" doesn't mean "fetch this code from github".  It just refers to the module's name.  By walking up the parent directories and finding go.mod, Go realises that the named module you are referring to is already on your filesystem as part of your project, and uses that directly.  This is why it works to use random module names like example.com/test

I'm not following this, I thought that was exactly why I put in the "github.com/pfarrell51/<modulename>"

in the source directory structure, and therefor in the github 

https://github.com/pfarrell51/gows repository

so if someone wanted to use my PID code or my quaternion code, it would be easy and automatic

For somebody on a remote system, yes.

On your own system, let's say you have the following tree:

~/projects/cmd      # contains go.mod with name github.com/pfarrell51/cmd

~/projects/cmd/foo

~/projects/cmd/bar

In the "foo" subdirectory, there is some code which says

    import "github.com/pfarrell51/cmd/bar"

When you compile this code, go finds the go.mod file *in your own filesystem* (in the enclosing directory).  It knows that ~/projects/cmd is github.com/pfarrell51/cmd.  Therefore, github.com/pfarrell51/cmd/bar can be found at ~/projects/cmd/bar (as long as that subdirectory doesn't have its own go.mod file).

Hence it doesn't go off to github to fetch github.com/pfarrell51/cmd/bar - which would be very confusing, since this is a package inside the module you're actively developing, and may not even have been published to github at all yet.  It uses the local copy.

Now suppose you've finished it, and you push it to github.  A different person writes some code with

    import "github.com/pfarrell51/cmd/bar"

For their own code, they need to have their own go.mod file with their own module name.  The system can see easily that the module they're writing is not the same as the one they're importing.  In this case, "go mod tidy" will go off to github and fetch the code, i.e. *your* code which *their* code depends on, and drop it into $GOMODCACHE

I hope this makes a bit more sense!  There is a nice series of blog articles starting at https://go.dev/blog/using-go-modules, although this assumes you know the old behaviour whereas really this is historic now.

Regards,

Brian.

[pat2...@gmail.com]

I've separated my code into separate subdirectories, added a go.mod

ran go mod tidy on each.

I'm mostly back where I started, which a better source file tree

I'm trying to test the "treesort" package from the "Donovan and Kernigan" The Go programing language book.

When I connect into the treesort subdirectory, you can see the files, but I get a bad GOROOT error trying to do a "go test ."

treesort$ ls
go.mod  treesort.go  treesort_test.go

pfarrell@Alien15:~/whome/sandbox/gows/treesort$ cat go.mod
module github.com/pfarrell51/gows/treesort

go 1.19

pfarrell@Alien15:~/whome/sandbox/gows/treesort$ go test .
# github.com/pfarrell51/gows/treesort

treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program Files\Go\src\treesort)

FAIL    github.com/pfarrell51/gows/treesort [setup failed]
FAIL

How can I get past this?
Thanks

Pat

[Sean Liao]

output of `go env` please

- sean

--
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/4b365c67-6f3d-4edc-97d5-dbe505604818n%40googlegroups.com.

[Kurtis Rader]

On Windows Go is normally installed to C:\Program Files\Go. You should not put your source code inside that directory. Put the source for your projects somewhere else such as %HOME%/go.

--

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/4b365c67-6f3d-4edc-97d5-dbe505604818n%40googlegroups.com.

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[pat2...@gmail.com]

On Wednesday, November 23, 2022 at 6:31:51 PM UTC-5 se...xxxx wrote:

output of `go env` please

I am using WSL (bash under Windows 11)

Shell env:

 env
HOSTTYPE=x86_64
LESSCLOSE=/usr/bin/lesspipe %s %s
LANG=C.UTF-8
WSL_DISTRO_NAME=Ubuntu
USER=pfarrell
PWD=/home/pfarrell/whome/sandbox/gows/treesort
HOME=/home/pfarrell
_=/usr/bin/env
pfarrell@Alien15:~/whome/sandbox/gows/treesort$

treesort$ go env
treesort$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\pfarrell\AppData\Local\go-build

set GOENV=C:\Users\pfarrell\AppData\Roaming\go\env

set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\pfarrell\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows

set GOPATH=C:\Users\pfarrell\go

set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct

set GOROOT=C:\Program Files\Go

set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.19.2
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\pfarrell\sandbox\gows\treesort\go.mod
set GOWORK=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\pfarrell\AppData\Local\Temp\go-build2617285960=/tmp/go-build -gno-record-gcc-switches
pfarrell@Alien15:~/whome/sandbox/gows/treesort$

[its unclear how the "GOPATH" was set, as it is not set in the shell env.]

Please note, the current pwd is

$ pwd
/home/pfarrell/whome/sandbox/gows/treesort

There is no such directory as the error message is reporting:

" (C:\Program Files\Go\src\treesort)"

There is a file, where the go installation process put a bunch of source files, so there is

" (C:\Program Files\Go\src)"

/mnt/c/Program Files/Go/src$ ls
Make.dist       bufio          cmd        debug     go      internal   mime       reflect   strconv   time
README.vendor   buildall.bash  cmp.bash   embed     go.mod  io         net        regexp    strings   unicode
all.bash        builtin        compress   encoding  go.sum  log        os         run.bash  sync      unsafe
all.bat         bytes          container  errors    hash    make.bash  path       run.bat   syscall   vendor
all.rc          clean.bash     context    expvar    html    make.bat   plugin     run.rc    testdata
archive         clean.bat      crypto     flag      image   make.rc    race.bash  runtime   testing
bootstrap.bash  clean.rc       database   fmt       index   math       race.bat   sort      text

For all of the above I am using WSL (bash under Windows 11)

Just for fun, I tried Windows Power Shell (which I never use)

'C:\Program Files\go\bin\go.exe' test .
# github.com/pfarrell51/gows/treesort
treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program Files\go\src\treesort)

FAIL    github.com/pfarrell51/gows/treesort [setup failed]
FAIL

Thanks

Pat

 

 

[pat2...@gmail.com]

On Wednesday, November 23, 2022 at 7:00:35 PM UTC-5 kra...XXX wrote:

On Windows Go is normally installed to C:\Program Files\Go. You should not put your source code inside that directory. Put the source for your projects somewhere else such as %HOME%/go.

My source files are not under "C:\Program Files\Go"

They are under a separate directory:

/home/pfarrell/whome/sandbox/gows/treesort

The error message contains an invented path that does not exist

[pat2...@gmail.com]

Just in case my use of the "windows installer" for go and then using WSL/bash

was confusing assorted magic env variables, I uninstalled/deleted the Windows installed version

then I downloaded the "linux" version, and did the usual "sudo tar " install

Made no difference

Get the same error message 

$ cat go.mod
module github.com/pfarrell51/gows/treesort

go 1.19

$ go test .

# github.com/pfarrell51/gows/treesort

treesort_test.go:11:2: package treesort is not in GOROOT (/usr/local/go/src/treesort)

[Kurtis Rader]

In your reply to the request for `go env` output you say "For all of the above I am using WSL (bash under Windows 11)". It looks like you're using the native Windows Go toolchain from WSL. I would not expect that to work and that is likely the reason you're having problems. You should install Go for Linux in WSL and use that. Note that "bash under Windows" isn't an accurate description of WSL (although, it is a widely used one). WSL is really a way to run Linux side-by-side with Windows in a manner akin to what you would get with a third-party tool like VMware and with sharing of filesystems. Running a native Windows program from WSL might work but you cannot assume that is true.

--

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/e8814b02-d072-4272-a12b-4509d353666cn%40googlegroups.com.

[Kurtis Rader]

Show us the output of `which go`. I'm not convinced you're using a native Linux 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/337a21ff-6c06-440d-9aa9-89aa4a1d071an%40googlegroups.com.

[pat2...@gmail.com]

I tried that about 20 minutes ago (messages may have crossed in the usenet cloud).

 I uninstalled the Windows go world

and downloaded the linux version and installed it under WSL

Made no difference

Now there no "windows go.exe

just the nice 'go' executable 

$ which go
/usr/local/go/bin/go

pfarrell@Alien15:~/whome/sandbox/gows/treesort$ go version
go version go1.19.3 linux/amd64

[Brian Candler]

Can you show the first 10 lines of your "treesort.go" and "treesort_test.go" files please?

I'm looking for the package lines and the import lines in particular.

[pat2...@gmail.com]

Sure 

 

cat treesort.go

// Copyright © 2016 Alan A. A. Donovan & Brian W. Kernighan.
// License: https://creativecommons.org/licenses/by-nc-sa/4.0/

// See page 101.

// Package treesort provides insertion sort using an unbalanced binary tree.
package treesort

// !+
type tree struct {
        value       int
        left, right *tree
}

cat treesort_test.go

// Copyright © 2016 Alan A. A. Donovan & Brian W. Kernighan.
// License: https://creativecommons.org/licenses/by-nc-sa/4.0/

package treesort

import (
        "fmt"
        "math/rand"
        "sort"
        "testing"
        "treesort"
)

func TestSort(t *testing.T) {
        data := make([]int, 50)
        for i := range data {
                data[i] = rand.Int() % 50
        }

[Brian Candler]

Your error comes from the spurious import of "treesort" in treesort_test.go.  (You are already inside package treesort; there is nothing to import)

With this line:

$ go test .
# example.com/blah
treesort_test.go:11:2: package treesort is not in GOROOT (/usr/local/go/src/treesort)
FAIL    example.com/blah [setup failed]
FAIL

Without this line: it works, once I've completed the code.

$ cat treesort_test.go

// Copyright © 2016 Alan A. A. Donovan & Brian W. Kernighan.
// License: https://creativecommons.org/licenses/by-nc-sa/4.0/

package treesort

import (

        //"fmt"
        "math/rand"
        //"sort"
        "testing"

)

func TestSort(t *testing.T) {
        data := make([]int, 50)
        for i := range data {
                data[i] = rand.Int() % 50
        }
}

$ go test .
ok      example.com/blah    (cached)

[pat2...@gmail.com]

Thanks

That seems to be the solution

[thepud...@gmail.com]

Hi Pat,

FWIW, I pulled together a TLDR on modules some time ago that I think hits upon each of the different issues you encountered in this thread. It also tries to summarize the core modules concepts, along with a bit of advice on how to stay on the "happy path" when starting out with Go modules. It is located here:

  https://stackoverflow.com/a/57314494/11210494

That might be worth a quick read, especially if you found anything puzzling so far.

It is likely also worthwhile to go through the official Go modules tutorial from the Go project:

  https://go.dev/doc/tutorial/create-module

Finally, looking over the thread, it seems you started by chasing how to set GOROOT, which makes sense given the main error message you first saw mentions GOROOT.

GOROOT was a bit of a red herring, and I opened an issue suggesting that error message be modified to something more helpful:

  #56965 -- cmd/go: consider reducing use of the word 'GOROOT' in error messages
  https://github.com/golang/go/issues/56965
 
Feel free to comment there or here if you have any additional thoughts on what would have made your journey simpler.

Best regards,
thepudds

[pat2...@gmail.com]

Thanks
I've read the official tutorial and your create-module docs.
They help, but I am still having issues getting this to hang together.
I got the treesort example to work.

Now I'm creating a new module, in a new subdirectory of my repositories
and I've done the go mod init

I have three go source files in the directory and the generated go.mod file
goprorename.go is what will eventually be a module/library of nice code.
goprorename_test.go is the test driver. Each of these two files are "package goprorename"
in the source.
main.go is a trivial file to run in the shell, creating an executable, probably named main.exe
that can accept shell arguments and call the nice code methods and functions.

I can't get the automatic compilation to work. i can't get testing to work. I can't get
the main/main.exe created.

Here are the contents of the go.mod and the top lines of each of the three go source files.

It has to be someting trivial that I am doing wrong or missing.
Thanks
Pat

pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ head -n 15 go.mod
module github.com/pfarrell51/gows/goprorename

go 1.19
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ head -n 15 goprorename.go
// rename files created by a GoPro into a single, sensible
// ordering of files so that the order is obvious for easy processing
// by other utulities such as RaceRender
//
// goPro naming conventions: https://community.gopro.com/s/article/GoPro-Camera-File-Naming-Convention?language=en_US

package goprorename

import (
        "fmt"
        "io/fs"
        "regexp"
        "strings"
)

pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ head -n 15 goprorename_test.go
// test driver for gopro rename utility
package goprorename

import (
        "fstest"
        "testing"
)

func TestProcessFile(t *testing.T) {

        fsys := fstest.MapFS{
                "file.go":                {},
                "subfolder/subfolder.go": {},
                "subfolder2/another.go":  {},
                "subfolder2/file.go":     {},
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ head -n 15 main.go
// shell program to rename files created by a GoPro into a single, sensible
// ordering of files so that the order is obvious for easy processing
// by other utulities such as RaceRender
//
// goPro naming conventions: https://community.gopro.com/s/article/GoPro-Camera-File-Naming-Convention?language=en_US

package main

import (
        "fmt"
        "github.com/pfarrell51/gows/goprorename"
        "os"
)


pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ go build .
found packages goprorename (goprorename.go) and main (main.go) in /home/pfarrell/whome/sandbox/gows/goprorename
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ go build goprorename
package goprorename is not in GOROOT (/usr/local/go/src/goprorename)
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ go build main
package main is not in GOROOT (/usr/local/go/src/main)
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ go build main.go
main.go:11:2: found packages goprorename (goprorename.go) and main (main.go) in /home/pfarrell/whome/sandbox/gows/goprorename


// these two compile cleanly when explicitly built.
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ go build goprorename.go
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ go build goprorename_test.go

[Volker Dobler]

You cannot have multiple packages (in your case main and goprorename)

in one folder. This has nothing to do with modules. You must but these

three files into two different folders based on their package declaration.

You might want to work through https://go.dev/doc/code

V.

[Brian Candler]

Plus, you don't need to do a "go mod init" in each subdirectory.  The top-level directory names the module and the package within it; you can refer to packages in subdirectories using this module name with the subdirectory appended.

A typical layout would look like this:

(top level)

go mod init example.com/foo

[whatever.go]

package main

import "example.com/foo/bar"

import "example.com/foo/baz"

....

(subdirectory "bar")

[whatever.go]

package bar

import "example.com/foo/baz"  // if required

...

(subdirectory "baz")

[whatever.go]

package baz

import "example.com/foo/bar"  // if required

...

You can test all this in the playground: 

https://go.dev/play/p/-PR3oartg0t

[pat2...@gmail.com]

thanks, and the playground is nice.

I think this is saying that if I want a baz and bar executable (chmod +x)
then I need the "package main" in separate folders/directories

I don't think I'm close enough to understanding this stuff to focus on optimizing it to
the fewest possible go.mod files, but I'll keep this in mind if I can get to the point of
creating a few source files, driving and testing them without blood on my desk from banging my
head into it.

Thanks
Pat

p.s. all my code is in my github reposities, with the real github path in the code I've posted. 

[Brian Candler]

On Saturday, 10 December 2022 at 05:50:53 UTC pat2...@gmail.com wrote:

thanks, and the playground is nice.

I think this is saying that if I want a baz and bar executable (chmod +x)
then I need the "package main" in separate folders/directories

Yes.  The approach I use (which I borrowed from some other project) is to have

cmd/baz/

cmd/bar/

bin/

directories, with cmd/{baz,bar}/ containing *.go files for each executable.  Then at the top level,

go build -o bin ./...

 

will make everything, and stick the binaries in the 'bin' directory.  The binaries will be named after their enclosing directories, i.e. "baz" and "bar".  Alternatively you can build them separately, e.g.

(cd cmd/baz; go build .)

You only need a single go.mod file at the top level.  If that declares the module as github.com/xxx/yyy, then people can build and install your binaries individually as, for example,

go install github.com/xxx/yyy/cmd/baz@latest

I'm not sure the official way to install *all* the binaries at once, but this seems to work:

go install github.com/xxx/yyy/...@latest