Add command line option to omit or only use certain rulesets

[david-a-wheeler]

It'd be nice if the command line let you select the rulesets.

[Ubadub]

@suchow I want to work on this if it's okay with you. I was thinking --i to explicitly include certain packages and --o to explicitly omit certain packages

[david-a-wheeler]

Great by me!

[suchow]

@Ubadub

Yes.

How does the following sound to you as a design spec?

--include or -i and a list of check names (e.g., wallace.uncomparables) runs the linter with only the given checks.

--exclude or -e and a list of of check names (e.g., wallace.uncomparables) runs the linter with all the checks except for those given.

[david-a-wheeler]

Sounds good!

[Ubadub]

@suchow exactly what I was thinking. Do you want to assign this to me? I'm going to go ahead and fork this later today and start working on it.

What version python are you guys using?

[suchow]

@Ubadub Yes, though GitHub doesn't make it possible to assign issues to people outside the repo owner's organization. Our codebase is compatible with 2 and 3, and Travis tests both.

[Ubadub]

@suchow I started work on this, but a quick question: how would I actually interact with the app from within the directory? calling python command_line.py gives "SystemError: Parent module '' not loaded, cannot perform relative import" because the parent directory is not a module

How can I actually run the proselint command from within the app?

[suchow]

Is the goal to be able to run proselint and have it reflect the current state of the code on your system? What I do is run python setup.py develop from within the root proselint/ directory and then interact with it using the command line.

[david-a-wheeler]

@suchow: No, the goal of this issue is to be able to say, on the command line, what rules to use/ignore without mucking with a configuration file.

[suchow]

@david-a-wheeler I think we may be talking past each other. I was responding to @Ubadub's most recent question.

[Ubadub]

@suchow I've run into an issue, but this is my first time working with click so maybe I'm missing something. Click allows either options or arguments. If I set this as an option, I can't allow an indefinite number of args (nargs can't be set to -1 with option, which is how you allow for). On the other hand, if I set it as an argument, I can set nargs to -1, BUT I can only do so for one argument. Unfortunately there are three different arguments that require nargs to be -1: files, --include, and --exclude

I was wondering if, unless there is some click-compatible solution to this problem that I haven't thought of, you'd be open to switching to a different command line python package.

[suchow]

@Ubadub which package?

[suchow]

Another way we could do this would be to allow .proselintrc to included named sets of rules, and then you could --include set_name to include only the rules in set_name, or, if the set_name is a specific rule, only that rule. This would help with #40 and some other issues that would benefit from modes.

[Ubadub]

Docopt? @suchow

[suchow]

@Ubadub I'd prefer to stick with Click and use the above --exclude and --include + .proselintrc technique if that works for you. It will help with other functionality we want to build out, too.

[Ubadub]

Alright. What would the sets be? @suchow

[perlpilot]

Greetings! A coworker introduced me to proselint today and this issue sounds very similar to the first thing that occured to me. Which was ...

I wonder if you can create specific types of policies for proselint and easily switch out your rc file. Like if you're writing a resume, you'll want one set of checks, but if you're writing a technical paper, you'll want another or if you're writing a short sci-fi story you'll want still another set of checks.

I was thinking it would be more like this though:

    $ proselint --style=resume

and it would look for a file in ~/.proselint/styles called resume.proselint that's in the same format as the rc file and use the appropriate rules from that file.

What do you guys think?

[Tatsh]

I am wondering why proselint does not check various places for proselintrc instead of only the 'system' version. Instead it gets the full path (dirname) to __file__ and appends .proselintrc.

https://github.com/amperser/proselint/blob/master/proselint/command_line.py#L31 https://github.com/amperser/proselint/blob/master/proselint/command_line.py#L51

It should be checking, similar to most applications (like cURL):

/etc/proselintrc
~/.proselintrc

Also, this can be either appending or overriding completely. It would be better to have a default safe /etc/proselintrc and then allow the user override with their own. This way the user becomes aware of new options as they get added.

When I installed the package onto the machine permanently (with Portage), it always read from /usr/lib64/python3.4/site-packages/proselint/.proselintrc and this seems strange. Honestly first time I've seen a package of any kind do this for looks to be a configuration file.

[suchow]

@Tatsh Yes, that would be a great enhancement.

1. Can you move this to a separate issue?
2. How do I convince you to take a stab at implementing this?

[Tatsh]

1. Sure.
2. I was already sort of implementing it via simple sed calls believe it or not but I guess now I can make a proper patch.

Other things I've fixed via sed: https://github.com/Tatsh/tatsh-overlay/blob/master/app-text/proselint/proselint-0.5.1.ebuild#L25