loosen dev dependencies

Some of the dependencies in requirements/dev-requirements.in and requirements/dev-requirements.txt are too strict to be used in Debian.

In particular:

coverage == 4.4.0
pylint == 2.1.1

I suggest you use >= instead of == for all the dependencies.

@jbicha Can you explain what exactly is the issue ?

From my understanding, the dev requirements should not be an issue for packages as they are not required by BuildStream, they are only required for running tests and developing BuildStream, which we use tox for.

For pylint for example, it is important that in CI we always use exactly the same version wherever we run tests, bumping the version of pylint used should itself also be gated on CI; otherwise newer versions of pylint inevitably end up introducing new linter errors, such that we cannot easily tell if a commit being tested introduced breakage, or if a random new version of pylint introduced the error.

I cannot recall off hand why coverage is pinned, but there are probably breaking combinations and pinning it was safest; of course again we only use this for collecting coverage reports of tests, which again are run under tox.

Maybe if you can explain exactly the issue you are facing, we can reorganize things to work better for everyone :)

Generally, we prefer to run build tests during the build in Debian.

I tried enabling the tests in Debian, ignoring the mismatched versions, but the tests still fail and I'm not sure whether the tests are even useful in Debian.

Build log

https://launchpad.net/ubuntu/+source/buildstream/1.2.4-1/+build/16397849

mentioned in commit 7b5cdafa

I see, from the looks of the build log, it appears the remaining problem is some confusion / import errors with some directories which have a .pybuild/ directory (not sure how that can appear during regular python3 setup.py test invocation).

For the versions, it is true that we have separated .in (loose requirements) from .txt (specific requirements) files such that we can separate the general requirements from the tested set of dependencies; so it should be actually fine to change these to >= in the .in files.

EDIT: Further, it appears that we should have a way to ignore the .txt files at python3 setup.py build and python3 setup.py install time; as I think the setup.py will currently only read the .txt version. Actually this is untrue, invocations of setup.py always consider the .in files; so if we can remove the restrictions then this should "Just Work".

That said, today I have been testing both master and bst-1.2 branches against an updated set of requirements, and the tests have been failing... trying to find out if this is being caused by a new coverage version right now.

Follow up: I can confirm that BuildStream tests are failing with coverage >= 4.4.2, tests still run fine with coverage == 4.4.1.

Update: Since landing !1179 (merged), using coverage in tests becomes optional.

Perhaps a decent compromise here would be to:

• Stop pinning pylint to an exact version
• Stop requiring coverage at all when running tests if coverage is disabled

mentioned in commit c67b2a0a

mentioned in merge request !1189 (merged)

mentioned in commit 02639b9b

mentioned in commit eb6d1690

closed via merge request !1189 (merged)

mentioned in commit 36171a07

mentioned in commit 9feb7e4a

mentioned in merge request !1203 (merged)

mentioned in commit 132c8f13

This should be fixed in the next 1.2.x bugfix release with !1203 (merged)