New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for configuration and removed executable check #24

Merged
merged 6 commits into from Dec 15, 2014

Conversation

Projects
None yet
4 participants
@evilhamsterman
Contributor

evilhamsterman commented Dec 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@dmnd

dmnd Dec 12, 2014

Member

👍 from me

Member

dmnd commented Dec 12, 2014

👍 from me

@evilhamsterman

This comment has been minimized.

Show comment
Hide comment
@evilhamsterman

evilhamsterman Dec 12, 2014

Contributor

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.

Contributor

evilhamsterman commented Dec 12, 2014

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 added a commit that referenced this pull request Dec 15, 2014

Merge pull request #24 from evilhamsterman/master
Add support for configuration and removed executable check

@dmnd dmnd merged commit 65b3c79 into AtomLinter:master Dec 15, 2014

@dmnd

This comment has been minimized.

Show comment
Hide comment
@dmnd

dmnd Dec 15, 2014

Member

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

Member

dmnd commented Dec 15, 2014

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

@A-M-R

This comment has been minimized.

Show comment
Hide comment
@A-M-R

A-M-R Jul 27, 2015

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.

A-M-R commented Jul 27, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment