Permit editable install of bleeding edge astroid in bleeding edge pylint

[Pierre-Sassoulas]

Steps to reproduce

1. When bleeding edge astroid is 2.x+1.0-dev0
2. And pylint require astroid < 2.x+1
   3.We can't install astroid in editable mode and this is really problematic during development

See discussion with @DanielNoord here

Possible solutions

• Do not increase version for bleeding edge astroid. Increase only when we really release astroid ?
  Con: The bleeding edge astroid is advertising falsely that it's compatible with 2.x but is in fact not
• Permit a wider range for astroid in bleeding edge pylint ? Reverting when we release ?
  Con: Need to revert the astroid < 2.x+2 when releasing pylint for astroid 2.x

[DanielNoord]

@Pierre-Sassoulas From your experience how often is the latest pylint main incompatible with latest release of astroid?

[Pierre-Sassoulas]

What happen somewhat often is that a "bug" is fixed in astroid and the pylint test suite needs an adaptation to remove disable for old false positive / fix old false negative and upgrade the test suite. See pylint-dev/pylint#5246 for example.

[Pierre-Sassoulas]

Originally we used bleeding edge astroid in pylint, but it means the main branch can break at any time.

[DanielNoord]

Ah, so the problem is that our CI fails with bleeding edge even though pylint itself doesn't necessarily break. As in, pylint itself can work with the bleeding edge but all of our tests suite jobs will fail if we don't update the test suite. Hmm, I wonder if there is a good solution to that that allows both.

[Pierre-Sassoulas]

Regarding the real breaking changes it should not be a problem. If pylint breaks it means the deprecation period in astroid was too short, or the effort to migrate too slow. It's also true for other libraries relying on astroid so it's a kind of canary in the mine.

[DanielNoord]

I wonder if we can do something in our workflow file that resets the dependency for astroid to a non bleeding edge without having to manually update the requirement every time we update the astroid requirement 🤔

[DanielNoord]

Trying to wrap my head around this, but:
If we pin astroid to a specific version (astroid==2.9.2) in requirements_test_min like we currently do in pylint but allow astroid>=2.9.2,<=2.10.0-dev0 in setup.py and we make sure to first install -r requirements_test_min and then do install -e . in the CI wouldn't this be fixed? We would satisfy the requirements from setup.py by downloading 2.9.2 first but would also allow anybody to install the latest dev version of astroid without errors from pylint.
Since 2.10.0-dev0 comes before 2.10.0 we wouldn't allow 2.10.0, so any actual breaking changes will still need to incorporated into astroid. (Although obviously on a 2.9 > 2.10 upgrade they are not supposed to happen).

[Pierre-Sassoulas]

Imo This could work as 2.10.0-dev0 is never published so it can't be recovered by users, but we might get questions if someone check the dependencies and wonder what the <= dev0 version is about.

[DanielNoord]

We can add a comment explaining why we pin like that?