Skip to content

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

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
Closed
abergmeier opened this issue Nov 13, 2018 · 7 comments
Closed

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

abergmeier opened this issue Nov 13, 2018 · 7 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Unreleased

Comments

@abergmeier
Copy link

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
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
@mvdan mvdan added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Nov 13, 2018
@abergmeier
Copy link
Author

abergmeier commented Nov 13, 2018 •
edited
Loading

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
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.

@ghost
Copy link

ghost commented Nov 14, 2018 •
edited by ghost
Loading

@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
Copy link
Author

abergmeier commented Nov 16, 2018 •
edited
Loading

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
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
@gopherbot gopherbot added the Tools This label describes issues relating to any tools in the x/tools repository. label Sep 12, 2019
@ALTree
Copy link
Member

ALTree commented Jun 18, 2021 •
edited
Loading

No updates for almost 3 years, assuming this is no longer needed.

@ALTree ALTree closed this as completed Jun 18, 2021
@golang golang locked and limited conversation to collaborators Jun 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
5 participants
@abergmeier @mvdan @ALTree @gopherbot @matloob