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

x/tools/go/packages: not handling non-known files #28766

Open
abergmeier opened this Issue Nov 13, 2018 · 6 comments

Comments

Projects
None yet
5 participants
@abergmeier
Copy link

abergmeier commented Nov 13, 2018

What version of Go are you using (go version)?

$ go version

1.11.1

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/user/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go-1.11"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.11/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/src/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build126572623=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Trying to use go/packages, we face the problem, that all this works fine - unless we need non-known files (these are currently not mapped in .e.g go list). As such, searching for file=myfile.go works fine but file=whatever.yml does not. Also, whatever.yml is not added to the OtherFiles slice, since go list only works with "known" file extensions (e.g. foo.h).
As a result, "non-known" files can currently no be found using go/packages when using the goList driver.

What did you expect to see?

It would be great if go list would also expose "non-known" files and thus be able to search them via pattern in go/packages. otherfile=whatever.yml would be ok as a pattern, too.

@mvdan

This comment has been minimized.

Copy link
Member

mvdan commented Nov 13, 2018

Why would you expect those files to be included? They are not part of a Go package, and OtherFiles is documented to include "other source files". That is, any other files that can be built as part of the Go package.

If you need to find a file on disk next to a Go file, it's likely easiest to take the Go file's directory and see if the filename you're after exists there.

@mvdan mvdan changed the title go/packages not handling non-known files x/tools/go/packages: not handling non-known files Nov 13, 2018

@gopherbot gopherbot added this to the Unreleased milestone Nov 13, 2018

@abergmeier

This comment has been minimized.

Copy link

abergmeier commented Nov 13, 2018

Why would you expect those files to be included?

Because semantically, you often can only test via loading non-source files.
What is the story for testing then? Remote loading files?
Especially since AFAIK go/packages should work regardless of go cli, pants, bazel, etc.

@mvdan

This comment has been minimized.

Copy link
Member

mvdan commented Nov 13, 2018

Sorry, I don't understand what you mean. Do you mean that non-source files in a package's directory can be required for the package's tests to succeed?

That's certainly reasonable, and it's why go mod vendor includes such non-source files. But I'm not sure to what degree that explains their presence in go/packages.

@opennota

This comment has been minimized.

Copy link

opennota commented Nov 14, 2018

@abergmeier You can put these files in the testdata directory, if I correctly understand your use case.

$ go help test | grep -A1 testdata
The go tool will ignore a directory named "testdata", making it available
to hold ancillary data needed by the tests.

Then you load them in your tests by name or using something like filepath.Glob("testdata/*")

@abergmeier

This comment has been minimized.

Copy link

abergmeier commented Nov 16, 2018

load them in your tests by name

Can you be a bit more specific?
Currently I fetch my module via go/packages, then get the absolute path of a known source file and build the absolute path to testdata depending on that.

@matloob

This comment has been minimized.

Copy link
Contributor

matloob commented Dec 4, 2018

Hi,

As far as go/packages goes, this is working as intended: The file= query to go/packages only works for Go files.

We might be able to help you fix your problem, but I think we need some more information on what you're trying to do: What do you mean by fetching your module? Why do you need the absolute path of testdata?

I'll assign this bug back to you for now. Please assign it back once you've responded

@matloob matloob assigned abergmeier and unassigned matloob Dec 4, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment