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

lint: add flag for checking dependencies #164

Open
dominikh opened this issue Aug 24, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@dominikh
Copy link
Owner

commented Aug 24, 2017

Currently, our tools run on the explicitly provided packages. Add a flag (-deps or -r(ecursive) maybe) that also checks all transitive dependencies. This is to ensure that the entire code base is free of issues. Some users may want to run this all the time, some only when adding/updating a dependency. Checking dependencies shouldn't add much of a cost: we already load these packages, and that's the most expensive step.

We probably shouldn't check the standard library, though. It has a lot of "funky" code and interactions with internals that cause a higher than average number of false positives.

Another question is whether the tests of dependencies should also be checked.

@dominikh dominikh added this to the 2017.3 milestone Nov 1, 2017

@dominikh dominikh removed this from the Next feature release milestone Jul 26, 2018

@dominikh

This comment has been minimized.

Copy link
Owner Author

commented Apr 27, 2019

Update in 2019, the following is no longer true:

Checking dependencies shouldn't add much of a cost: we already load these packages, and that's the most expensive step.

We can now apply aggressive caching to dependencies and can reuse export data, but have to load packages we wish to check from source. However, we can drop the source from memory after we're done checking a package, so this will primarily affect runtime, not memory use.

@myitcv

This comment has been minimized.

Copy link

commented May 4, 2019

This would in effect be equivalent to the -deps flag to go list, correct?

For those people in favour of this proposal, I'd be interested in understanding whether the magic all package (see go help packages) satisfies/doesn't satisfy their needs:

When using modules, "all" expands to all packages in the main 
module and their dependencies, including dependencies
needed by tests of any of those.

There was some discussion about all and std in golang/go#26317 FYI

@dominikh

This comment has been minimized.

Copy link
Owner Author

commented May 4, 2019

This would in effect be equivalent to the -deps flag to go list, correct?

Aside from the fact that we'd filter out the standard library, yes.

For those people in favour of this proposal, I'd be interested in understanding whether the magic all package (see go help packages) satisfies/doesn't satisfy their needs:

Do keep in mind that all will only work in module mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.