Skip to content
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

go: go.mod file not found in current directory or any parent directory #109

Closed
rleighton opened this issue Mar 19, 2021 · 23 comments · Fixed by #194
Closed

go: go.mod file not found in current directory or any parent directory #109

rleighton opened this issue Mar 19, 2021 · 23 comments · Fixed by #194

Comments

@rleighton
Copy link

I get:

go: go.mod file not found in current directory or any parent directory

However:

bash-3.2$ ls go.mod
go.mod

The command:

xgo -x --deps https://www.sqlite.org/2020/sqlite-autoconf-3320300.tar.gz --depsargs '--disable-fts4 --disable-fts5 --disable-rtree --disable-static-shell' --pkg internal/log_analysis/datalake/database_api/snowflake/driver/main --targets=linux/amd64 -out main --tags 'libsqlite3 linux' -dest out/bin/internal/log_analysis/datalake/database_api/snowflake/driver/main .

Any ideas?

This worked with go 1.13 but now I have to move to 1.16 because of other changes in the code base.

@techknowlogick
Copy link
Owner

Do you have an example repo that I could try this on?

@rleighton
Copy link
Author

rleighton commented Mar 19, 2021

I don't but thanks for asking. If I can't sort this maybe I can craft one.

I'm wondering if it is related to any of this new 1.16 changes: https://blog.golang.org/go116-module-changes.

Interestingly, if I run with -go go-1.15.10 it works BUT my application uses the new 1.16 embed feature and so it fails build.

@rleighton
Copy link
Author

Found the issue , tiny PR coming. The change is specific to a local build.

@rleighton
Copy link
Author

rleighton commented Mar 20, 2021

The issue is resetting config.Repository before the test for go.mod.

I don't have permissions to post a PR. This is the diff:

commit 66c5a7348e45f209e851114ae735bd53f37f1ec6 (HEAD -> russ-fix-local-module-builds)
Author: Russell Leighton <[email protected]>
Date:   Sat Mar 20 07:10:31 2021 -0400

    Fix repo path setting bug for local builds

diff --git a/xgo.go b/xgo.go
index a341db0..961ecaf 100644
--- a/xgo.go
+++ b/xgo.go
@@ -255,19 +255,19 @@ func compile(image string, config *ConfigFlags, flags *BuildFlags, folder string
        locals, mounts, paths := []string{}, []string{}, []string{}
        var usesModules bool
        if strings.HasPrefix(config.Repository, string(filepath.Separator)) || strings.HasPrefix(config.Repository, ".") {
-               // Resolve the repository import path from the file path
-               config.Repository = resolveImportPath(config.Repository)
-
                // Determine if this is a module-based repository
-               var modFile = config.Repository + "/go.mod"
-               _, err := os.Stat(modFile)
-               usesModules = !os.IsNotExist(err)
+               if _, err := os.Stat(config.Repository + "/go.mod"); err == nil {
+                       usesModules = true
+               }
 
                // Iterate over all the local libs and export the mount points
                if os.Getenv("GOPATH") == "" && !usesModules {
                        log.Fatalf("No $GOPATH is set or forwarded to xgo")
                }
                if !usesModules {
+                       // Resolve the repository import path from the file path
+                       config.Repository = resolveImportPath(config.Repository)
+
                        for _, gopath := range strings.Split(os.Getenv("GOPATH"), string(os.PathListSeparator)) {
                                // Since docker sandboxes volumes, resolve any symlinks manually
                                sources := filepath.Join(gopath, "src")

@rleighton
Copy link
Author

I don't but thanks for asking. If I can't sort this maybe I can craft one.

I'm wondering if it is related to any of this new 1.16 changes: https://blog.golang.org/go116-module-changes.

Interestingly, if I run with -go go-1.15.10 it works BUT my application uses the new 1.16 embed feature and so it fails build.

1.15 worked because I had GOPATH set.

@techknowlogick
Copy link
Owner

Awesome, thanks :) Let me try to put this together as a PR.

@rleighton
Copy link
Author

Do have an idea when this might merge? We have obviously a working forked version but it would make our builds easier when this is updated. Thank you !

@serbantanasa
Copy link

serbantanasa commented Mar 29, 2021

Hi @techknowlogick @rleighton I've hit this issue too -- seems to be a 6 line fix. I'd push a PR but don't have the permissions.

Here's a git patch:

From b81da5dd77c6d0934d7a79064a6c287bba6f0ee9 Mon Sep 17 00:00:00 2001
From: serbantanasa <[email protected]>
Date: Tue, 23 Mar 2021 12:56:04 -0400
Subject: [PATCH] fix xgo issue
​
---
 xgo.go | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)
​
diff --git a/xgo.go b/xgo.go
index a341db0..a6f46bc 100644
--- a/xgo.go
+++ b/xgo.go
@@ -255,19 +255,18 @@ func compile(image string, config *ConfigFlags, flags *BuildFlags, folder string
 	locals, mounts, paths := []string{}, []string{}, []string{}
 	var usesModules bool
 	if strings.HasPrefix(config.Repository, string(filepath.Separator)) || strings.HasPrefix(config.Repository, ".") {
-		// Resolve the repository import path from the file path
-		config.Repository = resolveImportPath(config.Repository)
-
-		// Determine if this is a module-based repository
-		var modFile = config.Repository + "/go.mod"
-		_, err := os.Stat(modFile)
-		usesModules = !os.IsNotExist(err)
+		if _, err := os.Stat(config.Repository + "/go.mod"); err == nil {
+			usesModules = true
+		}
 
 		// Iterate over all the local libs and export the mount points
 		if os.Getenv("GOPATH") == "" && !usesModules {
 			log.Fatalf("No $GOPATH is set or forwarded to xgo")
 		}
 		if !usesModules {
+			// Resolve the repository import path from the file path
+			config.Repository = resolveImportPath(config.Repository)
+
 			for _, gopath := range strings.Split(os.Getenv("GOPATH"), string(os.PathListSeparator)) {
 				// Since docker sandboxes volumes, resolve any symlinks manually
 				sources := filepath.Join(gopath, "src")
-- 
2.24.3 (Apple Git-128)
​

@serbantanasa
Copy link

any news?

@rleighton
Copy link
Author

rleighton commented Apr 13, 2021

@techknowlogick ping?

LogicalChaos added a commit to SpectraLogic/xgo that referenced this issue Apr 16, 2021
@thebaer
Copy link

thebaer commented May 8, 2021

I'm seeing same issue in our WriteFreely project... Running this command produces the same error, despite there being a go.mod file in the current directory where this is being run from:

xgo --targets=linux/amd64, -dest build/ -tags='sqlite' -out writefreely ./cmd/writefreely

Not sure if we need to change the command, or if this is a bug in xgo, but this used to work.

@makew0rld
Copy link

@thebaer It's a bug in xgo. You can use the patch above, or just run xgo with go1.15 instead of 1.16.

@thebaer
Copy link

thebaer commented May 10, 2021

Thanks! Adding -go go-1.15.x fixed this for me.

thebaer added a commit to writefreely/writefreely that referenced this issue May 10, 2021
This forces xgo to use Go 1.15, to work around a bug with Go modules:
techknowlogick/xgo#109 (comment)

This also uses the correct Darwin and Windows binary names to prevent
failures in the `make release` process.
@darkn3rd
Copy link

I am not sure if related, but I ran into issues with xgo and go 1.16 that requires GO111MODULE=auto. So I created my own image:

ARG GOVERSION=1.16.0
FROM techknowlogick/xgo:go-${GOVERSION}
# https://github.com/techknowlogick/xgo/issues/104
RUN go env -w GO111MODULE=auto

And during build process:

docker build -f release/xgo.Dockerfile -t dgraph/xgo:go-${GOVERSION} --build-arg GOVERSION=${GOVERSION} .
export XGO_IMAGE_OPT="-image dgraph/xgo:go-${GOVERSION}"
xgo -x -go="go-$GOVERSION" --targets= linux/$GOARCH $XGO_IMAGE_OPT -buildmode=exe .

techknowlogick added a commit that referenced this issue May 25, 2021
@techknowlogick
Copy link
Owner

I've just created #121 using the patch above, and will merge it hopefully once tests pass.

@jyap808
Copy link
Contributor

jyap808 commented Jul 17, 2021

Test case fails. See PR for more details.

@beastawakens
Copy link

Would really appreciate getting this in, causing me a lot of pain at the moment!

techknowlogick added a commit that referenced this issue Jul 23, 2021
* gomod fixes for go1.16

patch from: #109 (comment)

* Update test_pr.yml

* Update test_pr.yml

* kludge

* re-enable eth smoke

* Update xgo.bats

* apply feedback from Z
@techknowlogick
Copy link
Owner

Closing as linked PR has now been merged. Will be a sec before CI builds/publishes the new images.

@jyap808
Copy link
Contributor

jyap808 commented Jul 23, 2021

This still fails for the ethereum/go-ethereum test case. More so it thinks it passes but produces an incorrect binary.

$ stat github.com/ethereum/go-ethereum-linux-amd64
  File: github.com/ethereum/go-ethereum-linux-amd64
  Size: 151904          Blocks: 304        IO Block: 4096   regular file

$ file github.com/ethereum/go-ethereum-linux-amd64
github.com/ethereum/go-ethereum-linux-amd64: current ar archive

@beastawakens
Copy link

Yeah, I updated to the latest image and it still produces the same error for me (go: go.mod file not found in current directory or any parent directory) 😞

@techknowlogick
Copy link
Owner

oh darn, thanks for letting me know. I've reopened this so I can look into it.

@techknowlogick
Copy link
Owner

ok, I've been looking at this a bit.

I was missing a bit of the puzzle, https://github.com/techknowlogick/xgo/blob/main/xgo.go#L261 looks to see if the directory that is passed has a go mod, however as mentioned above this fails for the geth case (where the go.mod file is in a parent). From my debugging the reason for that is /tmp/eth/cmd/geth is the path mounted into the container, not /tmp/eth (which is the directory with go.mod). I suspect that using go env GOMOD, mounting in the path with go.mod, then building from requested subdir is the appropriate solution.

@michaellenaghan
Copy link

So... has this been resolved? I see references to 1.18 and 1.19 in the commits.

zeripath added a commit that referenced this issue Jan 15, 2023
This PR substantially restructures the xgo dockers creating a separate toolchain container, go-version container and then a merged container with the build.sh and xgo. This should in future allow for more caching and allows pr test cases to avoid rebuilding the whole toolchain.

In doing this I've noticed and fixed a number of bugs:
1. Yet another bug relating to remote paths that would cause a #181 and #109
2. The default naming for "packages" on module builds is incorrect and unhelpful. (#174) The default name will now be: modulename/pack-... 
3. Use mkdir -p /deps instead of /deps to permit reuse of the /deps dir

Fix #174
Fix #181 
Fix #164 
Fix #109 

Signed-off-by: Andrew Thornton <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants