Add a field to pass options or parameters to analyzer service

[mingshun]

Is it possible to add a field to let the API caller to pass some options or parameters to analyzer service?

Most of the analyzer executables (like jshint, go vet and so forth) can take options to specified their behaviors while running. The ability for caller to do so can make the analysis process more controllable.

Different analyzer executables may take different kinds of options or parameters, make the field a string may have the most compatibility. And I think it should be added to ShipshapeContext proto.

[thefallentree]

ping, anyone can responsd here?

[ciera]

Yes, we hadn't gotten around to implementing this yet since many analyzers presume their config file is a separate file in the system. For example, jshint uses a .jshintrc file for configuration, and pylint uses a .pylintrc.

Is there a particular analyzer that you are trying to configure that does not already have one of these files?

[mingshun]

@ciera Maybe we can pass the options in a universal form, such as json or xml. Then build the configuration file before running the analyzer executable in the analysis service. That's why I think the field holds the analyzer configuration should be a string. We can put configurations for more than one analyzer.

[supertriceratops]

Note that protocol buffers (e.g. shipshape_context.proto) provide a
universal form (like json).

Do you have a specific analyzer in mind? Where would the options come from
to pass to the analyzer?

On Thu, May 26, 2016 at 1:44 AM, mingshun [email protected] wrote:

@ciera https://github.com/ciera Maybe we can pass the options in a
universal form, such as json or xml. Then build the configuration file
before running the analyzer executable in the analysis service. That's why
I think the field holds the analyzer configuration should be a string. We
can put configurations for more than one analyzer.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#120 (comment)

[mingshun]

@supertriceratops
Yeah. The options are all for the specific analyzer. Provide configure for every possible analyzer over the json structure just like:

[
    {"analyzer": "jshint", "options": {}},
    {"analyzer": "go_vet", "options": {}},
    {"analyzer": "checkstyle", "options": {}}
]

Put the options of the specific analyzer under the options field in the specific json object.

The options should come from the RPC API caller no matter how the RPC client implements.