Hello there,
so I have added PyLint checks to travis. It nicely makes sure that PRs I get submitted become clean.
However, for each PyLint release, e.g. 2.0.0, there will be a bunch of findings that are new, and will to be found, leading to the Travis builds to fail due to PyLint, all the time now.
How to approach that. Is there a way I could have enforced using 1.9.2 on the "master" branch for Travis (and probably "develop" too), and use the latest greatest PyLint for "factory" only. Anyone know if that is possible, somehow, anybody doing something like that? Or maybe install a given version, but make it an error if that version is not the most recent on only the factory branch, what are people doing in this regard?
Yours, Kay
Hey,
On Tue, Jul 17, 2018 at 09:38:13AM +0200, Kay Hayen wrote:
However, for each PyLint release, e.g. 2.0.0, there will be a bunch of findings that are new, and will to be found, leading to the Travis builds to fail due to PyLint, all the time now.
How to approach that. Is there a way I could have enforced using 1.9.2 on the "master" branch for Travis (and probably "develop" too), and use the latest greatest PyLint for "factory" only. Anyone know if that is possible, somehow, anybody doing something like that? Or maybe install a given version, but make it an error if that version is not the most recent on only the factory branch, what are people doing in this regard?
You'd usually use requirements.txt files with exact version pinning - ideally not only for pylint, but for all your dependencies and tools, to ensure deterministic, reproducable results.
Then you can use https://requires.io/ or https://pyup.io/ to get notifications (or pull requests) to periodically update the pinned versions.
Florian
Hello Florian,
thanks for your reply.
How to approach that. Is there a way I could have enforced using 1.9.2 on the "master" branch for Travis (and probably "develop" too), and use the latest greatest PyLint for "factory" only. Anyone know if that is possible, somehow, anybody doing something like that? Or maybe install a given version, but make it an error if that version is not the most recent on only the factory branch, what are people doing in this regard?
You'd usually use requirements.txt files with exact version pinning - ideally not only for pylint, but for all your dependencies and tools, to ensure deterministic, reproducable results.
Then you can use https://requires.io/ or https://pyup.io/ to get notifications (or pull requests) to periodically update the pinned versions.
That sounds very nice. But you wouldn't normally put pylint into the standard requirements, would you, so you would have a dedicated, separate requirement file for it, to use with these services?
Right now, I am using on inline copies of scons which are used on platforms where apt-get install scons won't work. And I the same with appdirs. So I have no need yet for such files.
I just added one with PyLint now, before I was doing this in the install second of Travis: python -c 'import sys;exit(sys.version_info[:2] not in ((2,6), (3,3), (3,6)))' || pip install pylint
I blacklisted 3.6 for an error message that was not reproducible outside of Travis. Obviously that was with no 2.x version of PyLint. With pip syntax this might be more easily expressed and commented too. This is what I am trying right now:
# PyLint wouldn't be installable on 2.6 and not work with 3.3 pylint == 1.9.2 ; python_version < '2.7' pylint == 2.0.0 ; python_version >= '3.4'
That approach of externally having these checked, makes sense to me however. And I will use a "requirements.txt" for for optional requirements too now. Nuitka will just happen to work without them installed too. Getting those notifications and even PRs seems fine by me.
Yours, Kay
On Wed, Jul 18, 2018 at 09:01:39AM +0200, Kay Hayen wrote:
Hello Florian,
thanks for your reply.
How to approach that. Is there a way I could have enforced using 1.9.2 on the "master" branch for Travis (and probably "develop" too), and use the latest greatest PyLint for "factory" only. Anyone know if that is possible, somehow, anybody doing something like that? Or maybe install a given version, but make it an error if that version is not the most recent on only the factory branch, what are people doing in this regard?
You'd usually use requirements.txt files with exact version pinning - ideally not only for pylint, but for all your dependencies and tools, to ensure deterministic, reproducable results.
Then you can use https://requires.io/ or https://pyup.io/ to get notifications (or pull requests) to periodically update the pinned versions.
That sounds very nice. But you wouldn't normally put pylint into the standard requirements, would you, so you would have a dedicated, separate requirement file for it, to use with these services?
I often see a requirements.txt (with runtime dependencies) and a requirements-dev.txt (with test runners, linters, etc.) in projects.
I personally like to go even further and have one requirements file for every job on Travis (i.e. tests/pylint/flake8/...): https://github.com/qutebrowser/qutebrowser/tree/master/misc/requirements
I also have a script to automatically rebuild them, but you're probably not going to need that if you just rely in pyup/requires.io: https://github.com/qutebrowser/qutebrowser/blob/master/scripts/dev/recompile...
Florian
Hello Florian,
That sounds very nice. But you wouldn't normally put pylint into the standard requirements, would you, so you would have a dedicated, separate requirement file for it, to use with these services?
I often see a requirements.txt (with runtime dependencies) and a requirements-dev.txt (with test runners, linters, etc.) in projects.
So I went with that approach, which requires.io also supported out of the box, very nice.
I personally like to go even further and have one requirements file for every job on Travis (i.e. tests/pylint/flake8/...): https://github.com/qutebrowser/qutebrowser/tree/master/misc/requirements
Yes, sparing resources for them by specializing totally makes sense. I only have one job, but for all Python versions there, and I think I should have one dedicated for Travis, so I can add "redbaron" to development without making Travis download stuff not needed by it. These files can include one another as I have seen, so no duplication needed.
Anyway, thanks for the input. I had read of these things, but never realized I should have the issue myself.
Yours, Kay
participants (2)
-
Florian Bruhin -
Kay Hayen