--display-cop-names from .rubocop.yml?

[dankohn]

Can I specify to always use the flag --display-cop-names from my .rubocop.yml?

[padde]

We have a similar problem. We use rubocop with jish/pre-commit for Git commit hooks and want commits to be prevented only when issues with severity of error or fail are present. We can do this with the command line flag --fail-level error, but unfortunately pre-commit does not offer the ability to customize the flags passed to rubocop. I also opened an issue at jish/pre-commit#175 for this.

In any case, it would be nice to be able to specify per-project defaults in .rubocop.yml for all command line arguments.

[bbatsov]

Not sure about this. I don't want to introduce more complexity to the config, but I recognize the usefulness of being able to pass some command line params by default. Guess we can have an option like command-line args or something like that or a separate file like .rspec.

@jonas054 @yujinakayama What do you think about this?

[padde]

I think aside from passing default command line options, it would still make sense to be able to configure display-cop-names and fail-level in rubocop.yml. It would be a great way to say "in our team, everything below an error is not critical" and have a central location to store this information. Of course, the command line options would need to override that.

[padde]

@jonas054 @yujinakayama @bbatsov any updates on this? I'd love to see something like this in rubocop.yml:

DisplayCopNames: true
FailLevel: error

Thanks for your hard work!

[jonas054]

I think @padde was right in opening an issue with jish/pre-commit. Commands take arguments. Tools that call external commands should be able to send arguments.

Should RuboCop implement default arguments though configuration anyway? Only if many people need it and can't solve their problems any other way. Because it would add complexity, and I'm not sure it's necessary.

[padde]

@jonas054 thanks for your feedback. Working myself on a PR for jish/pre-commit now ;-)

[bbatsov]

Should RuboCop implement default arguments though configuration anyway? Only if many people need it and can't solve their problems any other way. Because it would add complexity, and I'm not sure it's necessary.

I'd suggest we postpone this for now. I don't want to do changes to the configuration logic until @yujinakayama is ready with its redesign.

[salimane]

+1

[swrobel]

Just throwing in my $0.02 that it would be great to be able to configure CLI options from .rubocop.yml

[mockdeep]

Likewise, this would be really handy.

[mnquintana]

👍

This would be incredibly useful. We have a lot of student developers who may or may not remember to set all the correct flags when they run rubocop locally, so being able to configure them from .rubocop.yml would be a godsend.

[jonas054]

I think that what stops me or anyone from getting started on an implementation is the fact that there are today 20 command line options. Some of them make sense as configuration options, some don't. Some are easy to implement as configuration options, some are hard.

My suggestion is that we handle only the option originally requested in this issue; AllCops/DisplayCopNames. If more are wanted/needed we do them in separate issues.

[bbatsov]

Fair enough.

On Sunday, January 4, 2015, Jonas Arvidsson [email protected]
wrote:

I think that what stops me or anyone from getting started on an
implementation is the fact that there are today 20 command line options.
Some of them make sense as configuration options, some don't. Some are easy
to implement as configuration options, some are hard.

My suggestion is that we handle only the option originally requested in
this issue; AllCops/DisplayCopNames. If more are wanted/needed we do them
in separate issues.

—
Reply to this email directly or view it on GitHub
#1324 (comment).

Best Regards,
Bozhidar Batsov

http://www.batsov.com

[mnquintana]

@jonas054 @bbatsov Do you think it would be good if we made another "master" issue for tracking which flags people want added as config options?

[jonas054]

@mnquintana Yes, please create it.

[bbatsov]

I'm not fond of meta-issues that stay open forever. Let's wrap this first.
If other options are needed someone will certainly create tickets regarding
them.

On Sunday, January 4, 2015, Jonas Arvidsson [email protected]
wrote:

@mnquintana https://github.com/mnquintana Yes, please create it.

—
Reply to this email directly or view it on GitHub
#1324 (comment).

Best Regards,
Bozhidar Batsov

http://www.batsov.com

[mnquintana]

@bbatsov Fair enough. What about a label / milestone? (Just something to keep track of each individual issue as they crop up.)

[bbatsov]

Having a custom label for this type of issues sounds fine.

[tansaku]

I'd love to be able to use:

AllCops/DisplayCopNames

and

AllCops/DisplayStyleGuide

would be hugely useful for our team - particularly with houndci integration