We could make it so that for other vulnerability chains as well, it doesn't ask for user input anymore. But I think this change is definitely good and a step in the right direction, I'm happy to merge :D

(fwiw I don't think my comment on the issue was very clear.)

That's a good point. I can make that change so that we stop it for all chains.

So the last commit stops asking for all chains, but I'm not 100% satisfied. There aren't many better options without touching too much (e.g. making an Interactive/Mode object, or a Config object and making interactive one of its elements). This is easy but inelegant.

I have not fixed Travis' complaints about too many returns inside that function. While that is true, refactoring this function isn't trivial so I'd like to get some input on what's the preferred path forward, both for Travis and the general solution.

I agree it's inelegant, but it's good code 👍

Maybe in the find_vulnerabilities def we can do something like

>>> class Interactive(): # Maybe in `vulnerability_helper.py`
... def __init__(self):
... self.on = False
... def __bool__(self):
... return self.on
... 
>>> interactive.on = interactive_mode # Where we currently do `interactive = False`

Where we rename the interactive arg to interactive_mode in that function def. I'm happy with whatever you prefer though, as I'm as unsure as you are.

Code Climate complains about a lot of things in the existing code, I don't know if there's anything we can do in this case.

(Gonna go ahead and merge 👍 , if that's okay, as it's good as-is.)

Sorry, I'm having a hard time finding time lately due to some personal commitments. I was working on a nicer approach, but I'm happy to see this merged and we can improve it later.

No worries @adrianbn 👍 Same here.