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

Too many ruby files. #129

Open
nroose opened this issue Dec 27, 2019 · 2 comments
Open

Too many ruby files. #129

nroose opened this issue Dec 27, 2019 · 2 comments

Comments

@nroose
Copy link

nroose commented Dec 27, 2019

I am getting
Errno::E2BIG: Argument list too long
for each of the tools that use the list of ruby files. This happens in debian and in MacOS. Seems like all of these tools can find the files without listing. Is there some reason to list them? If there is, then to support large projects, then a bunch of code would need to change to support the use of xargs. Or perhaps I am missing something?

@apiology
Copy link
Owner

apiology commented Jan 1, 2020

D'oh!

In addition to using something akin to xargs, generally tools support passing a list of files to analyze within a text file--that'd probably be the best thing to add for tools that support it, with a feature to break things up in xargs-like chunks if not.

@apiology
Copy link
Owner

apiology commented Jan 1, 2020

Seems like all of these tools can find the files without listing. Is there some reason to list them?

In general there's a tension between delegating a lot of decisions to the tools involved and having the quality gem have control. I've taken the approach that file selection is on the quality gem side of the line there - it uses the https://github.com/github/linguist gem to identify file types and allow configuration, which does file content sniffing (it's the same gem that github.com uses to figure out how to syntax highlight and render different files).

Some reasons why that has been a benefit:

  • We can exclude particular files from analysis because they can't be changed/shouldn't be changed/isn't worth being changed - think vendored files from other projects, etc.
  • Most tools aren't particularly sophisticated when finding files - they rely on file extensions alone. This can be a real bummer for tools like shellcheck, as if you have a shell file and choose not to use the .sh extension, it probably won't find it.

In any case, it'd be a bummer to break existing configuration of the file exclusion by changing policies, and those benefits have been compelling at least for the use I've seen, so my take is that adding support for the list-of-files-file and/or xargs-like approach seems right.

Note that we wouldn't want to use xargs directly, as I'd like to at least theoretically maintain Windows support. I've never tested it personally, but if someone wants to figure that out and add CI for it so I don't break it in the future, it seems like it ought to be within reach :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants