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

package in GOPATH shadows module #27

Closed
antong opened this issue Oct 24, 2018 · 4 comments · Fixed by #33
Closed

package in GOPATH shadows module #27

antong opened this issue Oct 24, 2018 · 4 comments · Fixed by #33

Comments

@antong
Copy link

antong commented Oct 24, 2018

On the go1.11 branch, packages within the module are shadowed by packages happening to be in GOPATH as well. This does not happen for regular Go, only GopherJS.

Consider the following layout, with GOPATH set to "/.../topdir/gopath".

topdir
├───foomod
│   └───bar
└───gopath
    └───src
        └───foo
            └───bar

$ cat foomod/go.mod
module foo

$ cat foomod/main.go
package main // import "foo"

import "foo/bar"

func main() {
        bar.Bar()
}

$ cat foomod/bar/bar.go
package bar

import "fmt"

func Bar() {
        fmt.Println("Hello from module foo!")
}

$ cat gopath/src/foo/bar/bar.go
package bar

import "fmt"

func Bar() {
        fmt.Println("Hello from GOPATH!")
}

With Go:

$ cd foomod/
$ go run .
Hello from module foo!

With gopherjs on branch go1.11 I get "Hello from GOPATH!". If I remove the version checked out in GOPATH, I get the expected "Hello from module foo!".

@myitcv
Copy link
Owner

myitcv commented Oct 24, 2018

Thanks very much for the repro @antong. Here is a copy-paste repro script for reference:

export GOPATH=$(mktemp -d)
export PATH=$GOPATH/bin:$PATH

# block: output
go env GOPATH
cd $GOPATH
git clone --depth=1 https://github.com/myitcv/gopherjs "$(cut -d':' -f1 <<< $GOPATH)/src/github.com/gopherjs/gopherjs"
go get -u github.com/gopherjs/gopherjs
cd /tmp
mkdir foomood
cd foomood
go mod init foo
cat <<EOD > main.go
package main

import "foo/bar"

func main() {
   bar.Bar()
}
EOD
mkdir bar
cat <<EOD > bar/bar.go
package bar

import "fmt"

func Bar() {
   fmt.Println("Hello from module foo/bar!")
}
EOD
cd $GOPATH
mkdir -p src/foo/bar
cat <<EOD > src/foo/bar/bar.go
package bar

import "fmt"

func Bar() {
   fmt.Println("Hello from GOPATH foo/bar!")
}
EOD
cd /tmp/foomood
go run .
gopherjs run *.go

gives:

$ go run .
Hello from module foo/bar!
$ gopherjs run *.go
Hello from GOPATH foo/bar!

I suspect this is somewhat related to #24... but in a strange way.

I'll investigate. Thanks again

@myitcv
Copy link
Owner

myitcv commented Oct 24, 2018

Per discussions with @marwan-at-work, a temporary fix for this (and @antong points this out above) is to set your GOPATH to something other than its current/default value. Something like /path/to/module/.gopath should suffice.

@myitcv
Copy link
Owner

myitcv commented Oct 24, 2018

e.g.

export PATH=$GOPATH/bin:$PATH
git clone https://github.com/myitcv/gopherjs /tmp/gopherjs
cd /tmp/gopherjs
go install
git clone https://github.com/marwan-at-work/marwanio /tmp/marwanio
cd /tmp/marwanio
export GOPATH=$PWD/.gopath
go mod init
gopherjs build

myitcv added a commit that referenced this issue Nov 23, 2018
build: fix GOPATH shadow bug

Fixes #27
myitcv added a commit that referenced this issue Nov 23, 2018
build: fix GOPATH shadow bug

Fixes #27
myitcv added a commit that referenced this issue Nov 23, 2018
build: fix GOPATH shadow bug

Fixes #27
@myitcv
Copy link
Owner

myitcv commented Nov 23, 2018

Finally getting around to this.

Now that #29 has landed, it's trivial to create repros for this sort of thing.

I've pushed up #32 as a starting point with a testscript repro. Fix hopefully to follow shortly.

myitcv added a commit that referenced this issue Nov 23, 2018
build: fix GOPATH shadow bug

Fixes #27
myitcv added a commit that referenced this issue Nov 23, 2018
build: fix GOPATH shadow bug

Fixes #27
myitcv added a commit that referenced this issue Nov 23, 2018
build: fix GOPATH shadow bug

Fixes #27
myitcv added a commit that referenced this issue Nov 27, 2018
This is a necessarily large PR to offer almost complete Go modules
support for GopherJS.

* We now use github.com/rogpeppe/go-internal to be able to write testscript
  tests
* A suite of testscript tests have been added to cover the major GopherJS
  commands operating in both GOPATH mode and module mode.  Includes a test to
  ensure that the bug raised in #27 is now properly fixed.
* The GopherJS tool and build packages have been heavily refactored in places to
  support Go modules. GopherJS support for Go modules follows the same patterns
  as the go tool.
* We fix the build cache to be a function of the augmented packages as opposed
  (incorrectly) to the unaugmented package files. This has a slight cost because
  of the way the augmentation code is currently written (this could be refactored
  in a later PR) because every file is unconditionally parsed. Main and test
  packages are not cached (again, we could change this in a later PR). Because it
  would just work.
* We fix the tests/run.go wrapper around the fixedbugs tests in the Go
  distribution to not perform a chdir into GOROOT; this does not work with
  modules.
* We tidy up .circleci/config.yml to split commands into their separate run
  sections where it makes sense to.
* We add genmodstubbs.go to automatically populate the stubs we need in
  testdata/mod for the loading of github.com/gopherjs/gopherjs/{js,nosync}.
* For a more current commentary on the Go module support in GopherJS see
  https://github.com/myitcv/gopherjs/wiki/Changes-in-module-aware-GopherJS

Fixes #27
myitcv added a commit that referenced this issue Nov 27, 2018
This is a necessarily large PR to offer almost complete Go modules
support for GopherJS.

* We now use github.com/rogpeppe/go-internal to be able to write testscript
  tests
* A suite of testscript tests have been added to cover the major GopherJS
  commands operating in both GOPATH mode and module mode.  Includes a test to
  ensure that the bug raised in #27 is now properly fixed.
* The GopherJS tool and build packages have been heavily refactored in places to
  support Go modules. GopherJS support for Go modules follows the same patterns
  as the go tool.
* We fix the build cache to be a function of the augmented packages as opposed
  (incorrectly) to the unaugmented package files. This has a slight cost because
  of the way the augmentation code is currently written (this could be refactored
  in a later PR) because every file is unconditionally parsed. Main and test
  packages are not cached (again, we could change this in a later PR). Because it
  would just work.
* We fix the tests/run.go wrapper around the fixedbugs tests in the Go
  distribution to not perform a chdir into GOROOT; this does not work with
  modules.
* We tidy up .circleci/config.yml to split commands into their separate run
  sections where it makes sense to.
* We add genmodstubbs.go to automatically populate the stubs we need in
  testdata/mod for the loading of github.com/gopherjs/gopherjs/{js,nosync}.
* For a more current commentary on the Go module support in GopherJS see
  https://github.com/myitcv/gopherjs/wiki/Changes-in-module-aware-GopherJS

Fixes #27
myitcv added a commit that referenced this issue Nov 27, 2018
This is a necessarily large PR to offer almost complete Go modules
support for GopherJS.

* We now use github.com/rogpeppe/go-internal to be able to write testscript
  tests
* A suite of testscript tests have been added to cover the major GopherJS
  commands operating in both GOPATH mode and module mode.  Includes a test to
  ensure that the bug raised in #27 is now properly fixed.
* The GopherJS tool and build packages have been heavily refactored in places to
  support Go modules. GopherJS support for Go modules follows the same patterns
  as the go tool.
* We fix the build cache to be a function of the augmented packages as opposed
  (incorrectly) to the unaugmented package files. This has a slight cost because
  of the way the augmentation code is currently written (this could be refactored
  in a later PR) because every file is unconditionally parsed. Main and test
  packages are not cached (again, we could change this in a later PR). Because it
  would just work.
* We fix the tests/run.go wrapper around the fixedbugs tests in the Go
  distribution to not perform a chdir into GOROOT; this does not work with
  modules.
* We tidy up .circleci/config.yml to split commands into their separate run
  sections where it makes sense to.
* We add genmodstubbs.go to automatically populate the stubs we need in
  testdata/mod for the loading of github.com/gopherjs/gopherjs/{js,nosync}.
* For a more current commentary on the Go module support in GopherJS see
  https://github.com/myitcv/gopherjs/wiki/Changes-in-module-aware-GopherJS

Fixes #27
myitcv added a commit that referenced this issue Nov 27, 2018
This is a necessarily large PR to offer almost complete Go modules
support for GopherJS.

* We now use github.com/rogpeppe/go-internal to be able to write testscript
  tests
* A suite of testscript tests have been added to cover the major GopherJS
  commands operating in both GOPATH mode and module mode.  Includes a test to
  ensure that the bug raised in #27 is now properly fixed.
* The GopherJS tool and build packages have been heavily refactored in places to
  support Go modules. GopherJS support for Go modules follows the same patterns
  as the go tool.
* We fix the build cache to be a function of the augmented packages as opposed
  (incorrectly) to the unaugmented package files. This has a slight cost because
  of the way the augmentation code is currently written (this could be refactored
  in a later PR) because every file is unconditionally parsed. Main and test
  packages are not cached (again, we could change this in a later PR). Because it
  would just work.
* We fix the tests/run.go wrapper around the fixedbugs tests in the Go
  distribution to not perform a chdir into GOROOT; this does not work with
  modules.
* We tidy up .circleci/config.yml to split commands into their separate run
  sections where it makes sense to.
* We add genmodstubbs.go to automatically populate the stubs we need in
  testdata/mod for the loading of github.com/gopherjs/gopherjs/{js,nosync}.
* For a more current commentary on the Go module support in GopherJS see
  https://github.com/myitcv/gopherjs/wiki/Changes-in-module-aware-GopherJS

Fixes #24
Fixes #27
myitcv added a commit that referenced this issue Nov 27, 2018
This is a necessarily large PR to offer almost complete Go modules
support for GopherJS.

* We now use github.com/rogpeppe/go-internal to be able to write testscript
  tests
* A suite of testscript tests have been added to cover the major GopherJS
  commands operating in both GOPATH mode and module mode.  Includes a test to
  ensure that the bug raised in #27 is now properly fixed.
* The GopherJS tool and build packages have been heavily refactored in places to
  support Go modules. GopherJS support for Go modules follows the same patterns
  as the go tool.
* We fix the build cache to be a function of the augmented packages as opposed
  (incorrectly) to the unaugmented package files. This has a slight cost because
  of the way the augmentation code is currently written (this could be refactored
  in a later PR) because every file is unconditionally parsed. Main and test
  packages are not cached (again, we could change this in a later PR). Because it
  would just work.
* We fix the tests/run.go wrapper around the fixedbugs tests in the Go
  distribution to not perform a chdir into GOROOT; this does not work with
  modules.
* We tidy up .circleci/config.yml to split commands into their separate run
  sections where it makes sense to.
* We add genmodstubbs.go to automatically populate the stubs we need in
  testdata/mod for the loading of github.com/gopherjs/gopherjs/{js,nosync}.
* For a more current commentary on the Go module support in GopherJS see
  https://github.com/myitcv/gopherjs/wiki/Changes-in-module-aware-GopherJS

Fixes #24
Fixes #27
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.

2 participants