Recursive gometalinting about gometalinter HOT 7 CLOSED

Unfortunately not all of the linters support recursion, which is why gometalinter does not provide it as an option. It could be emulated I guess, but that seems like it's a bit out of scope.

from gometalinter.

I also think that this would be a nice feature.

Isn't emulation somewhat simple?

run linter on each package directory

In my ci scripts I've worked around the issue by calling gometalinter on each sub-package, but that means I need to update ci scripts each time I add new sub-project which is unnecessary and error prone.

Adding gometalinter ./... would also mean that you get multiple package support no matter if linter supports it or not.

from gometalinter.

Sure it is simple, but my thought was that using find is just as easy:

find . -type d | xargs -n1 | gometalinter

That said, it sounds like people are interested in the feature, so I'll take a look.

from gometalinter.

👏

from gometalinter.

So, this change has made me realize I have been running gometalinter incorrectly all this time. I've been successfully (or so I thought) running it as gometalinter jobsetc/..., where jobsetc is the root of a repo containing a few packages. I erroneously thought that all of the linter tools would use the same package semantics as tools like go list.

With this changeset, the above command started crashing, and while trying to figure out why, I've learned a few things that may help others:

• Some linters support package lists, some only support directories/files, including "official" tools like gotype.
• All of the default linters support at least single argument that is a directory representing a package. This directory must be relative to $PWD.
• The logic for parsing package lists is not exposed by any official go library, but has been extracted by a 3rd party at https://github.com/kisielk/gotool. Some linters like structcheck use this package to support package lists.
• There is an open issue to make path pattern matching functions available to go programmers but it doesn't appear likely that it will make it into the standard library.
• Linters that don't support package lists will fail silently in gometalinter unless the debug flag is used, in which case you get warning: <linter> returned exit status <n>.
• gometalinter will exit with non-zero status if any linter finds issues, even if you use the --exclude flag. This makes relying on the exit status difficult.
• gometalinter now crashes on gometalinter jobsetc/... if the 'jobsetc' directory does not exist relative to $PWD. Or, more generally, it crashes if path arg ends with '/...' and that path can't be found by filepath.Walk().
• The recursion implementation in this changeset is not consistent with the package list semantics of go list, et al.
  • It doesn't ignore paths that start with _ like import path parsers do.
  • It doesn't ignore directories that are not packages (with no .go files in them), which will causes many of the linters to error out.

And I discovered a command that works for me:

(cd $GOPATH/src && go list jobsetc/... | xargs gometalinter)

I'm not sure if there is a good general solution for normalizing the inputs to the various linters, but I will try to make a pull request for the crashing issue. I'll create an issue for the --exclude issue as well; not sure what the solution is for that yet, though.

For those of you still reading, here's the breakdown of what inputs the default linters accept:

• go-nyet: accepts list of directories or files, recurses if ends with ...; ignores dirs that are not go packages
• go-cyclo: accepts list of directories or files, does not recurse, only processes *.go in each dir.
• deadcode: accepts list of directories only, passes dir to parser.ParseDir()
• go vet: When launched with go vet, accepts go list style import paths. When launched with go tool vet, accepts list of directories or files, not both at the same time, file list must be in same pkg; otw very similar to go-nyet.
• gotype: accepts single directory or list of files (or an entire pkg on stdin)
• golint: accepts single directory, directory ending in ..., list of files, or single import path,
• structcheck, errcheck, defercheck, varcheck: go list style import paths

from gometalinter.

Yes, it is unfortunately quite complicated because there's no "standard" mechanism used by all tools. Another complication is that some tools automatically check directories recursively (eg. go tool vet .) by default.

It's a mess, and basically the reason why I originally decided to check only one directory at a time.

PS. I merged your request and the --exclude issue should be fixed in the latest commit.

from gometalinter.

I think that last commit should fix the last of the issues.

The current behaviour is not 100% optimal, but seems to work in all cases that I've tested.

• Directories are recursed correctly: paths without .go files are skipped, paths with a leading _ or . are skipped.
• Each linter is called with exactly one path at a time. This is not optimal, as some linters (like errcheck) are much faster if called once with a single recursive path.

PS. Thanks for compiling that comprehensive breakdown.

from gometalinter.