python3 -m venv venv
source venv/bin/activate
python --version
pip install pylint
export PYTHONPATH=`pwd`
pylint --exit-zero -j 4 --reports=y -f parseable my_files/ tests/ | tee pylint.out
pylint --exit-zero --reports=y -f parseable my_files/ tests/ | tee pylint.out
pip uninstall pylint
pip install pylint==2.4.4
pylint --exit-zero -j 4 --reports=y -f parseable my_files/ tests/ | tee pylint.out
In Pylint 2.4.4 the summary report including Pylint score was shown even when using the -j option to control the number of cores used.
I would expect Pylint 2.5.0 to have the same behavior as 2.4.4 with a valid report along with the score being shown. This score not being shown breaks out CI/CD pipeline where we grep for the score to ensure it stays the same or improves.
(venv) [scharman@foomy_repo]$ pylint --version
pylint 2.5.0
astroid 2.4.0
Python 3.6.8 (default, Aug 7 2019, 17:28:10)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]
I'm seeing this problem, and another (bigger) problem with the new 2.5.0 version, coupled with the -j (--jobs / aka parallel) execution option. The same violations are repeated when j>1. In our TravisCI build engines, where we run on 30+ core machines to rapidly pylint our source (using j=0) -- the same pylint violation is now repeated 30+ times.
We funnel the pylint report in to our sonarqube system, where our poor dev team is now freaking out that their ~6k violations have mushroomed in to ~180k violations (the same violations repeated/duplicated).
Running with j=1 is not an option as it takes over 20 min to pylint a project with ~72k LOC.
This all worked fine in 2.4.4. I'm going to lock our CI process to that previous version of pylint until the broken -j / --jobs issues are fixed...
@bgehman We saw the same exact issue in our build with the -j option and issues being reported multiple times. The solution to getting the report to show (original issue) and the multiple reports was to simply not take advantage of parallel jobs for now.
@bobbyscharmann yeah, I hear ya. For us it simply just takes way too long with -j=1 (the default). Would add an additional 20+ minutes for our builds when not taking advantage of full parallelism.
I'm going with this hack (to lock us to 2.4.4 for now):
if [[ $(python --version) =~ Python\ 3.* ]]; then
# Locking to pylint 2.4.4 due to upstream 2.5.0 bug: https://github.com/PyCQA/pylint/issues/3547
echo "Python3: forcing pylint to version 2.4.4..."
export install_pip_version="pylint==2.4.4"
else
echo "Python2: Why are you still using this? installing latest pylint..."
export install_pip_version="pylint"
fi
if ! pip install $install_pip_version > /dev/null; then
echo "Failed to install pylint, skipping scans... Debug: found python files:"
printf '%s\n' "${pyfiles[@]}"
return 0
fi
echo "Running pylint, version: $(pylint --version)..."
pylint "${pyfiles[@]}" -j 0 -r n --msg-template="{path}:{line}: [{msg_id}({symbol}), {obj}] {msg}" > pylint-report.txt || true
tail -n 3 pylint-report.txt
Thank you, I can reproduce it as well, its definitely a regression.
Most helpful comment
Thank you, I can reproduce it as well, its definitely a regression.