Add support for configuration and removed executable check

[evilhamsterman]

The primary purpose of this request is to add support for configurations to allow you to set a pylint executable and pylintrc. This would solve issues #16, #14 and supersede the pull request in #21. It is important to be able to switch pylint executables because many times Linux distros include both python 2 and 3 now.

I removed the executable check for three reasons.

1. It decreases readability and adds unnecessary complexity to debug in the event that linter changes
2. As far as I can tell no other linters do this
3. Most importantly it causes the linter to silently fail from the perspective of the user. Every other linter will generate an error in the interface if the executable doesn't exist, while the error generally isn't very descriptive it at least lets the user know the linter failed. Since it is possible to change the pylint executable now if they enter a wrong executable they should be alerted.

[dmnd]

👍 from me

[evilhamsterman]

I should also note, I think this is a cleaner resolution for the closed issue #13 since people who have a nonstandard pylint-script.py can enter that as their executable rather than having to do some weird regexes to account for it.

[dmnd]

Thanks for this, merged and I'll publish a release in a few minutes.

[A-M-R]

I have seen this handled in both JetBrains PyCharm and ActiveState KomodoIDE by inheriting the the path of the library based on how the document or project is set.

As an example, if the programmer is working on a Py3 project, then there is either a project level preference where they set the path of the Python 3.X interpreter or the user preferences will have a section to add the path to the Python 2.X interpreter, then one for the Python 3.X interpreter.

After the paths are set, then, based on the project or document type, it will access the path for the correct interpreter and its library. All of the autocomplete and error checking functionality then points to that library, so that there are no version inconsistency.

I think that the idea of setting at the project level (JetBrains implementation) is smarter, as older projects won't run into issues of deprecatation so long as the Library remains intact and in place.