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.

Sign up for GitHub

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

Jump to bottom

gopherjs test ./with/relative/path failing #302

Closed
flimzy opened this issue Sep 10, 2015 · 4 comments · Fixed by #644
Closed

gopherjs test ./with/relative/path failing #302

flimzy opened this issue Sep 10, 2015 · 4 comments · Fixed by #644
Assignees
@dmitshur
Labels
bug gopherjs-tool Related to the gopherjs tool or its build system (but not the compiler itself). NeedsFix

Comments

@flimzy
Copy link
Member

flimzy commented Sep 10, 2015

The gopherjs test command fails when I specify an explicit path, while this works with standard go test. A simple proof:

$ go test
PASS
ok      github.com/flimzy/flashback     0.003s
$ go test .
ok      github.com/flimzy/flashback     0.005s

Similar tests with gopherjs in another directory:

$ gopherjs test
PASS
warning: system calls not available, see https://github.com/gopherjs/gopherjs/blob/master/doc/syscalls.md
ok      github.com/flimzy/flashback/webclient/pages/all 0.319s
$ gopherjs test .
import ".": import relative to unknown directory

Of course testing '.' isn't that useful, that just proved a simple test case. The same happens if I specify a full path:

$ go test ./couch/
ok      github.com/flimzy/flashback-server/couch        0.010s

And with gopherjs:

$ gopherjs test ./webclient/pages/all/
import "./webclient/pages/all/": import relative to unknown directory
@dmitshur
Copy link
Member

dmitshur commented Sep 10, 2015 •
edited

This is a known issue, was decided as "wontfix" at the time. See #148.

Edit: That might be incorrect. This appears to be a relative import path in CLI. Issue #148 was about relative import paths in Go code. Sorry for misleading.

@dmitshur
Copy link
Member

Also, to correct your terminology, go test ./couch/ is a relative import path. It's not a full import path. go test github.com/foo/bar/couch is a full import path. Relative import paths are those that contain . or .. elements.

@dmitshur dmitshur changed the title gopherjs test /with/explicit/path failing gopherjs test ./with/relative/path failing Sep 10, 2015
@flimzy
Copy link
Member Author

flimzy commented Sep 10, 2015

Thanks for the explanation. I hadn't thought to try github.com/.../... that's good enough for me.

@flimzy flimzy closed this as completed Sep 10, 2015
flimzy referenced this issue Oct 19, 2015
@dmitshur
README: Suggest working with Go packages by default.
1e66ca3 
When writing Go code that is something more than just a very short snippet, it helps to organize code as a Go package. It may contain 1 or more .go files in a directory.

`go build` is primarily used with Go packages, as in `go build import/path`. We should suggest the same use of `gopherjs build`. That will make it easier for users to get started and grow their code, because they'll be able to split into multiple .go files without having to update their build step.
@dmitshur dmitshur mentioned this issue Jan 17, 2016
Merged
@dmitshur dmitshur added the gopherjs-tool Related to the gopherjs tool or its build system (but not the compiler itself). label May 19, 2017
@dmitshur
Copy link
Member

I'm going to reopen and resolve this issue. /cc @slimsag

Sure, there's always the workaround of doing:

$ gopherjs test $(go list ./...)

But that's not nice and not friendly to new people who are used to being able to do things like go test ./....

I've prototyped a fix. It's not the most trivial fix, but still very manageable. Will send a PR soon.

@dmitshur dmitshur reopened this May 19, 2017
@dmitshur dmitshur self-assigned this May 19, 2017
dmitshur added a commit that referenced this issue May 20, 2017
@dmitshur
build: Try to get and use working directory, when possible.
f79744a 
Previously, in build.Import, the srcDir argument to importWithSrcDir
call was always empty string.

Ideally, the Import method should have a srcDir parameter and pass it
onwards. Then the caller (gopherjs tool, for example) can provide the
working directory, if available. However, this is an exported method
and changing its signature at this time is hard. Settle for an
intermediate solution of try to figure out working directory inside
Import, but continue to use empty string on failure (such as if in
GOARCH=js mode, e.g., inside browser).

This will be used by the gopherjs tool in the next commit to be able to
resolve relative import paths, such as "." or "./foo/bar".

The future plan is to bring all the "supported" code into gopherjs repo
for convenience, mark the build API as unstable and make breaking API
changes to bring it up to speed.

Helps #302.
dmitshur added a commit that referenced this issue May 20, 2017
@dmitshur
Expand import path patterns inside gopherjs tool.
d443444 
Use github.com/kisielk/gotool package to expand import path patterns in
gopherjs build, gopherjs install, and gopherjs test commands.

For example, "./..." can become {"."} or {"./foo", "./foo/bar",
"./foo/baz"}.

In gopherjs build command, only write output to working directory when
a single package is specified (and that package is a command). This
matches behavior of cmd/go tool.

Fixes #302.
dmitshur added a commit that referenced this issue May 20, 2017
@dmitshur
Remove special case for build/install/test with zero arguments.
975164a 
Previously, there was a special case to handle when user ran "gopherjs
build", "gopherjs install", or "gopherjs test", without specifying any
import paths via arguments.

The code to handle this special case was complicated and poorly
implemented, making assumptions about the first GOPATH workspace.

The code can be completely removed now, because of support for relative
import paths (#302) is resolved, and because gotool is guaranteed to
map zero arguments to ".":

	If args is empty, a single element "." is returned.

As a result, after this change, running "gopherjs build", "gopherjs
install", "gopherjs test" is equivalent to running "gopherjs build .",
"gopherjs install .", "gopherjs test ." respectively. There's less code
to accomplish the same task.
@dmitshur dmitshur mentioned this issue May 20, 2017
Merged
dmitshur added a commit that referenced this issue May 29, 2017
@dmitshur
build: Try to get and use working directory, when possible.
5a65b98 
Previously, in build.Import, the srcDir argument to importWithSrcDir
call was always empty string.

Ideally, the Import method should have a srcDir parameter and pass it
onwards. Then the caller (gopherjs tool, for example) can provide the
working directory, if available. However, this is an exported method
and changing its signature at this time is hard. Settle for an
intermediate solution of try to figure out working directory inside
Import, but continue to use empty string on failure (such as if in
GOARCH=js mode, e.g., inside browser).

This will be used by the gopherjs tool in the next commit to be able to
resolve relative import paths, such as "." or "./foo/bar".

The future plan is to bring all the "supported" code into gopherjs repo
for convenience, mark the build API as unstable and make breaking API
changes to bring it up to speed.

Helps #302.
dmitshur added a commit that referenced this issue May 29, 2017
@dmitshur
Expand import path patterns inside gopherjs tool.
606652a 
Use github.com/kisielk/gotool package to expand import path patterns in
gopherjs build, gopherjs install, and gopherjs test commands.

For example, "./..." can become {"."} or {"./foo", "./foo/bar",
"./foo/baz"}.

In gopherjs build command, only write output to working directory when
a single package is specified (and that package is a command). This
matches behavior of cmd/go tool.

Fixes #302.
dmitshur added a commit that referenced this issue May 29, 2017
@dmitshur
Remove special case for build/install/test with zero arguments.
c40709c 
Previously, there was a special case to handle when user ran "gopherjs
build", "gopherjs install", or "gopherjs test", without specifying any
import paths via arguments.

The code to handle this special case was complicated and poorly
implemented, making assumptions about the first GOPATH workspace.

The code can be completely removed now, because of support for relative
import paths (#302) is resolved, and because gotool is guaranteed to
map zero arguments to ".":

	If args is empty, a single element "." is returned.

As a result, after this change, running "gopherjs build", "gopherjs
install", "gopherjs test" is equivalent to running "gopherjs build .",
"gopherjs install .", "gopherjs test ." respectively. There's less code
to accomplish the same task.
dmitshur added a commit that referenced this issue May 29, 2017
@dmitshur
build: Try to get and use working directory, when possible.
25c3660 
Previously, in build.Import, the srcDir argument to importWithSrcDir
call was always empty string.

Ideally, the Import method should have a srcDir parameter and pass it
onwards. Then the caller (gopherjs tool, for example) can provide the
working directory, if available. However, this is an exported method
and changing its signature at this time is hard. Settle for an
intermediate solution of try to figure out working directory inside
Import, but continue to use empty string on failure (such as if in
GOARCH=js mode, e.g., inside browser).

This will be used by the gopherjs tool in the next commit to be able to
resolve relative import paths, such as "." or "./foo/bar".

The future plan is to bring all the "supported" code into gopherjs repo
for convenience, mark the build API as unstable and make breaking API
changes to bring it up to speed.

Helps #302.
dmitshur added a commit that referenced this issue May 29, 2017
@dmitshur
Expand import path patterns inside gopherjs tool.
7568072 
Use github.com/kisielk/gotool package to expand import path patterns in
gopherjs build, gopherjs install, and gopherjs test commands.

For example, "./..." can become {"."} or {"./foo", "./foo/bar",
"./foo/baz"}.

In gopherjs build command, only write output to working directory when
a single package is specified (and that package is a command). This
matches behavior of cmd/go tool.

Fixes #302.
dmitshur added a commit that referenced this issue May 29, 2017
@dmitshur
Remove special case for build/install/test with zero arguments.
db88776 
Previously, there was a special case to handle when user ran "gopherjs
build", "gopherjs install", or "gopherjs test", without specifying any
import paths via arguments.

The code to handle this special case was complicated and poorly
implemented, making assumptions about the first GOPATH workspace.

The code can be completely removed now, because of support for relative
import paths (#302) is resolved, and because gotool is guaranteed to
map zero arguments to ".":

	If args is empty, a single element "." is returned.

As a result, after this change, running "gopherjs build", "gopherjs
install", "gopherjs test" is equivalent to running "gopherjs build .",
"gopherjs install .", "gopherjs test ." respectively. There's less code
to accomplish the same task.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dmitshur dmitshur

Labels
bug gopherjs-tool Related to the gopherjs tool or its build system (but not the compiler itself). NeedsFix
Projects
None yet
Milestone
No milestone
2 participants
@dmitshur @flimzy