python-language-server: flake8 and pyflakes plugins are not working on Atom at least on Linux (and maybe other OSes)
This issue is being reported by multiple people, initially we thought it was ide-python https://github.com/lgeiger/ide-python/issues/191 but I think this is probably a pyls issue on Atom on at least Linux and maybe other OSes.
In a test conda environment, where I install only conda install python-language-server, if I configure ide-python in Atom to only enable flake8 and disable everything else and I open a python file I get no linting and the following console errors atom-console-pyls-flake8.log
It seems to have started happening with pyls >0.31.2
Atom 1.45 with the following conda environment:
# packages in environment at /home/hermidalc/soft/miniconda3/envs/pyls-test:
#
# Name Version Build Channel
_libgcc_mutex 0.1 conda_forge conda-forge
_openmp_mutex 4.5 0_gnu conda-forge
astroid 2.3.3 py38_1 conda-forge
autopep8 1.5 py_0 conda-forge
ca-certificates 2019.11.28 hecc5488_0 conda-forge
certifi 2019.11.28 py38h32f6830_1 conda-forge
entrypoints 0.3 py38h32f6830_1001 conda-forge
flake8 3.7.9 py38h32f6830_1 conda-forge
future 0.18.2 py38h32f6830_1 conda-forge
importlib-metadata 1.5.2 py38h32f6830_0 conda-forge
importlib_metadata 1.5.2 0 conda-forge
isort 4.3.21 py38h32f6830_1 conda-forge
jedi 0.15.2 py38_0 conda-forge
lazy-object-proxy 1.4.3 py38h1e0a361_2 conda-forge
ld_impl_linux-64 2.34 h53a641e_0 conda-forge
libffi 3.2.1 he1b5a44_1007 conda-forge
libgcc-ng 9.2.0 h24d8f2e_2 conda-forge
libgomp 9.2.0 h24d8f2e_2 conda-forge
libstdcxx-ng 9.2.0 hdf63c60_2 conda-forge
mccabe 0.6.1 py_1 conda-forge
ncurses 6.1 hf484d3e_1002 conda-forge
openssl 1.1.1e h516909a_0 conda-forge
parso 0.6.2 py_0 conda-forge
pip 20.0.2 py_2 conda-forge
pluggy 0.13.1 py38_0 conda-forge
pycodestyle 2.5.0 py_0 conda-forge
pydocstyle 5.0.2 py_0 conda-forge
pyflakes 2.1.1 py_0 conda-forge
pylint 2.4.4 py38_0 conda-forge
python 3.8.2 h8356626_5_cpython conda-forge
python-jsonrpc-server 0.3.4 py_0 conda-forge
python-language-server 0.31.9 py38h32f6830_0 conda-forge
python_abi 3.8 1_cp38 conda-forge
readline 8.0 hf8c457e_0 conda-forge
rope 0.16.0 py_0 conda-forge
setuptools 46.1.3 py38h32f6830_0 conda-forge
six 1.14.0 py_1 conda-forge
snowballstemmer 2.0.0 py_0 conda-forge
sqlite 3.30.1 hcee41ef_0 conda-forge
tk 8.6.10 hed695b0_0 conda-forge
ujson 1.35 py38h950e882_1002 conda-forge
wheel 0.34.2 py_1 conda-forge
wrapt 1.12.1 py38h1e0a361_1 conda-forge
xz 5.2.4 h516909a_1002 conda-forge
yapf 0.29.0 py_0 conda-forge
zipp 3.1.0 py_0 conda-forge
zlib 1.2.11 h516909a_1006 conda-forge
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 32 (14 by maintainers)
@ccordoba12 What I had to do is log pyls
flake8_lint.pyto file (stdout did not work for some reason, probably because atom messes with it)Also started atom with logging as
/usr/lib/atom/atom --executed-from="$(pwd)" --pid=$$ -f > atom.log 2>&1. It is supposed to have-loption, but it produces empty files, same fornohup.outBelow are attached the three log files
Hope that helps
UPD: I see at least two errors in the previous arguments to flake8:
;;. These originate from mysetup.cfg, which itself is a valid ini, understood by flake8:Nonein between'--filename=*.py'and'--ignore=E121. I don’t give a f where it comes from.So, I tried to run without my
setup.cfghaving pure defaults. And thisNoneis still there. Below are attached the new logs:And when I filter out this None, build the command and try running it manually, flake8 starts fine
Following the previous my investigation. A quick and dirty fix:
Tried it, everything works like a charm, both with my setup.cfg and without
Other people have been using the flake8 plugin successfully with other editors.
Please follow the instructions in my https://github.com/palantir/python-language-server/issues/769#issuecomment-620200190 above to give us more info from your side.
They are tested on Linux and Windows. Please check any previous PR to see that that’s the case.
Then I found a problem, that is, the CI detection environment only checks Windows and not Linux or other platforms, which may cause problems on other platforms.
Maybe we can use PyTest or other function check suite to check the results of the data we use or output. This may first solve the problem whether it is from Python instead of Atom.
No, it isn’t. This log just messed up with Atom and JS stuff also, in this form it’s more readable.
I don’t know where the problem is nor what’s its cause unless I can see a proper log file. And that problem (that server errors are not logged correctly) is an Atom problem.
I meant the package in Atom that does the integration with the python-language-server.