This may be far more information than you were looking for. Feel free to pick and choose whatever may be applicable to your particular use case.
Our Software Development Plan specifies the use of Anaconda. In particular, it requires the following settings in Packages/User/Anaconda.sublime-settings
:
...
"anaconda_linter_mark_style": "fill",
"anaconda_linter_phantoms": false,
"anaconda_linting_behaviour": "save-only",
...
Additionally, the SDP defines the following key bindings (e.g. Packages/User/Default (Linux).sublime-keymap
) that allow turning linting off (F12) and on (SHIFT+F12) on a file-by-file basis.
[
...
{ "keys": ["f12"], "command": "anaconda_disable_linting" },
{ "keys": ["shift+f12"], "command": "anaconda_enable_linting" }
...
]
Without going into the "how's" and "why's", one thing is for certain, it is virtually impossible for developers to ingore linting errors, but gives them a temporary out should they want to ignore linting errors.
Even so, this setup is not productive when viewing third-party code/packages, which can be peppered with PEP warnings for one reason or another. For this reason, our SDP recommends that developers create one or more separate ST3 projects, specifically intended for viewing third-party code.
For example, I peruse Flask, wxPython, Numpy, and other package sources regularly. These are individually added to a "Packages" project, which in turn disables Anaconda linting by default, using the following project settings (e.g. packages.sublime-project
)
{
"build_systems": [
...
],
"folders": [
...
],
"settings": {
"anaconda_linting": false
}
}
Whenever there is a need to inspect a package or other code, the corrsponding folder is dragged onto the project sidebar; allowing code inspection without linting. If it was a one-time viewing, the folder is removed from the sidebar.