search

palantir / python-language-server

An implementation of the Language Server Protocol for Python
MIT License
2.61k stars 283 forks source link

Conflict between required pyflakes version #782

Closed leszekpi closed 4 years ago

leszekpi commented 4 years ago

Publication of pyflakes 2.2.0 version revealed a conflict in dependencies between python-language-server (pyflakes>=1.6.0) and flake8(pyflakes<2.2.0,>-2.1.0).

I think the best solution would be to remove dependencies in python-language-server and rely only on flake8 definition.

ccordoba12 commented 4 years ago

Thanks for letting us know about it. We'll require pyflakes <2.2.0 for now then.

bnavigator commented 4 years ago

Publication of pyflakes 2.2.0 version revealed a conflict in dependencies between python-language-server (pyflakes>=1.6.0) and flake8(pyflakes<2.2.0,>-2.1.0).

For the record:

There is no conflict. pyflakes>=2.1.0,<2.2.0 satisfies both the original PyLS definition as well as the one coming from flake8 3.7.9. Pip is just not smart enough to resolve that properly https://medium.com/knerd/the-nine-circles-of-python-dependency-hell-481d53e3e025

PyLS builds fine with pyflakes 2.2.0 and flake8 3.8.0a2 https://gitlab.com/pycqa/flake8/-/merge_requests/417

ccordoba12 commented 4 years ago

@bnavigator, the error doesn't appear at build time but at runtime and (I think) it's generated by pkg_resources because flake8 declares pyflakes>2.1.0,<2.2.0 here:

https://github.com/PyCQA/flake8/blob/3.7.9/setup.cfg#L16

Therefore, @leszekpi's PR was the correct fix.

bnavigator commented 4 years ago

I did not contest that the PR is the correct fix. It fixes setuptools/pip's inability to do a proper dependency resolution at install time.

With "builds fine" I meant the unit tests succeed. There is no real build for pure Python modules.

Still, I wanted to state not for you, but for distribution maintainers and users without the desire to pin to eventually outdated software, that PyLS works fine with pyflakes 2.2.0 as long as the installed flake8 works with it.

ccordoba12 commented 4 years ago

I did not contest that the PR is the correct fix. It fixes setuptools/pip's inability to do a proper dependency resolution at install time.

Right, since pip doesn't have a solver it's not possible to expect other kind of result.

With "builds fine" I meant the unit tests succeed. There is no real build for pure Python modules.

Sure, I know that. But I thought you meant "building OpenSuse packages" for it (which is what conda and Linux distros do using the tarballs provided by Python projects).

Still, I wanted to state not for you, but for distribution maintainers and users without the desire to pin to eventually outdated software, that PyLS works fine with pyflakes 2.2.0 as long as the installed flake8 works with it.

Right. However, given the increasing interrelatedness of the Python package ecosystem, and the advice of the PyPA core developers, I think this kind of pins will become the norm.

I understand this will pose terrible difficulties to Linux maintainers as yourself, but I consider it's for the best.

bnavigator commented 4 years ago

There is a difference between pinning stuff for a specific environment (requirements.txt, conda recipes, distribution repositories) and overly constraining what a single package supports (setup.py). That tweet is targeted to the former, but you apply it to the latter. This SO answer explains it nicely.

ccordoba12 commented 4 years ago

That tweet is targeted to the former

I don't think so because Dustin is talking about releases maintainers upload to PyPI, not about how to use pip to install packages from requirements.txt or something similar (you can see that that's the case by looking at the tweets that come above the one I quoted).

This SO answer explains it nicely.

Quoting from that answer:

If you're releasing a library on PyPI, you should declare whatever dependencies you know about, but not pin to a specific version.

Clearly the should above (my emphasis) means that this is Nathaniel's advice (just like Dustin is advising to use hard pinning).

In any case, I'm in favor of following Dustin's advice in the projects me and my team maintain, sorry.

bnavigator commented 4 years ago

The whole twitter thread is about the new yanking feature.

To quote from the thread, emphasis by me:

Because releases on PyPI are immutable, pinning your dependencies (plus including hashes) ensures that you ALWAYS get the EXACT same distributions every time you install

As you say, it is for release maintainers. Not source code. After all, PyPA, PyPI, pip etc. is about packaging. setuptools is below that.