coala Next generation bears (v2) [$110]

2nd try to realize next generation bears. I'm trying to set up actionable steps.

TODO:

[ ] Remove Local/Global bear distinction.
- Just make everything a global bear and use simple for loops for now or an own multiprocessing.pool. I think this is better than making coala even more complex while having neglectable performance disadvantages IMO.
- Remove asynchronous processing of results from the CLI interactor. We should not focus on asynchronous processing of results but on simplification of logic. In the GUI results can be used asynchronously because the user can actually navigate back and forth so this makes a bit more sense here.
[ ] Simplify multiprocessing libraries. Ideally we should use a multiprocessing pool to get the bears done, maybe resolve dependencies before?
[ ] Make bear class a decorator or even an undecorated function.
- I think we really want bears to be specified like module.bear e.g. spacing.check_space_consistency or so.

Aug 17 '15 17:08 sils

thoughts about a bear:

[ ] A bear must yield results
[ ] A bear must be able to log stuff - elsewise it's impossible to implement them.
[ ] A bear must access settings - even such settings that do not yet exist
[ ] A bear must be able to access the results of (some) other bears.
[ ] bears should be run in parallel

I'll look into and propose an architecture that provides hopefully all of the above in a easy and thought-out way. We can then look at how to incorporate these things into coala.

Nov 07 '15 21:11 fneu

settings and dependencies should be expressed in a way that they can be determined before the bear is being run. We rather want to get rid of interactivity here, and, most likely, prepare everything for the bear beforehand.

This kind of conflicts with the goal of making bear-writing as simple as possible.

Nov 07 '15 21:11 fneu

@fneu yeah, I do agree with determining settings before, we can still use the same function signature as we use now. Problem is that the decorators change the signature so you'll have to deal with that.

I'm not sure if we maybe want to allow plugging bears into others dynamically somehow, may be useful for debugging. But really, let's not think about that right now. Determine everything before the run, that's nice.

Nov 07 '15 22:11 sils

This description sounds a lot like some kind of actor system 1 or some kind of Rx2 . I haven't looked if there was already some existing stuff in python, but that would indeed simplify a lot the code needed to fulfill the checking.

Nov 13 '15 21:11 jnavila

@jnavila cool, thanks for the feedback, we'll look at that.

Nov 13 '15 22:11 sils

Is this issue open to be worked on by new contributors?

Nov 20 '15 11:11 justuswilhelm

@justuswilhelm kind of, I wouldn't recommend starting with this one, it's a particularly hard thing. If you're interested please sync with us at https://gitter.im/coala-analyzer/coala .

Nov 20 '15 11:11 sils

I have worked out a prototype together with @Makman2 of which sounds like an actual feasible solution at https://github.com/coala-analyzer/next-gen-bears-prototype . I also think we might want to make a library out of that because that is pretty universally usable. Less complexity in coala.

Feb 04 '16 16:02 sils

A lot of the initial thoughts behind this issue are at: https://github.com/coala-analyzer/coala/issues/720 https://github.com/coala-analyzer/coala/issues/724 https://github.com/coala-analyzer/coala/issues/725

for reference