Pylint only fail on Travis CI but not local or GitLab CI

Languages Python
1

Here is the fail job.

It throws C0411 on all the import statements of dataclasses. However, when I run pylint on my local Win 10 machine, it does not throw the error. I have checked they have the same Python and pylint version.

I also have a GitLab CI that run the same job and it does not throws any errors.

If I move the packages like what it said in the log, it throws C0411 on my local machine.

Here is my config file

dist: xenial
language: python
jobs:
  include:
    - python: 3.7
      env: TEST_TYPE=pytest
    - python: 3.7
      env: TEST_TYPE=flake8
    - python: 3.7
      env: TEST_TYPE=pylint
before_install:
  - python --version
install:
  - pip install -r requirements.txt
  - if [[ $TEST_TYPE == 'pytest' ]]; then travis_retry pip install -U pytest>=4.0.1 pytest-cov>=2.6.0; fi
  - if [[ $TEST_TYPE == 'flake8' ]]; then travis_retry pip install -U flake8>=3.6.0; fi
  - if [[ $TEST_TYPE == 'pylint' ]]; then travis_retry pip install -U pylint>=2.1.1; fi
script:
  - |
    if [[ $TEST_TYPE == 'pytest' ]]; then
      pytest --version
      pytest --cov=aliceplex tests;
    fi
  - |
    if [[ $TEST_TYPE == 'flake8' ]]; then
      flake8 --version
      flake8 aliceplex;
    fi
  - |
    if [[ $TEST_TYPE == 'pylint' ]]; then
      pylint --version
      pylint aliceplex;
    fi
2

Looks like Pylint thinks dataclasses isn’t a standard import · Issue #2261 · PyCQA/pylint.

You need to update isort from Github head:

  • pip install -U git+https://github.com/timothycrosley/isort, or
  • add git+https://github.com/timothycrosley/isort into requirements.txt
3

@native-api How can it only happens on Travis CI if Python and pylint are the same version on other machine?

4

I’ve no idea. I’d need an MCVE for all other environments to say with confidence.
My current blind guess is you aren’t really using “the same versions” of something. E.g. Anaconda packages can have patches.

Note that the bug I linked to is not in pylint or Python but in isort (a pylint dependency).

5

@native-api

Here is the repo: https://github.com/joshuaavalon/pylint_bug
Here is the job: https://travis-ci.org/joshuaavalon/pylint_bug/builds/459728290

6

That’s not “MCVE for all other environments”.

Besides, did you try checking my clue yourself first? Like, check what isort you have, run pylint under debugger to see how it avoids the code path that leads to the error message.

FWIW, this is a Travis support forum, and AFAICS, the problem is not in Travis. So it’s your job to dig it further until and unless you get other evidence pointing to Travis.

7

Both Travis and my local show isort is 4.3.4.

My local machine and GitLab CI that use python official image which is also fine. I am asking here because it only fails in Travis CI.

8

https://travis-ci.org/native-api/pylint_bug/builds/460008448 has a trace of isort.SortImports(file_contents="").place_module("dataclasses") (this is what pylint calls when classifying a module.)

It returns 'FIRSTPARTY'. Locally in Win7, it returns 'STDLIB'.

Looking at the code and the variables I printed in build output, and comparing it with the output of the same code run locally with WinMerge, virtualenv affects the paths that isort uses.

Indeed, in a virtualenv, it returns FIRSTPARTY.

So, in your other environments, you’re probably not running pylint that belongs to, and inside a virtualenv, and that is the reason for the discrepancy.

I’ve no idea what this “FIRSTPARTY” is supposed to mean (isort's docs or code have no expalantion, the author probably thought it was obvious), so this is a bug in either isort (misclassifies the module) or pylint (misinterprets the “FIRSTPARTY” result as an external module).

9

So, in your other environments, you’re probably not running pylint that belongs to, and inside a virtualenv , and that is the reason for the discrepancy.

I am sorry to tell you that I run pylint inside virtualenv.
I use PyCharm which help me initialize virtualenv on new project.

Capture
Capture1086×786 33.4 KB

10

Sorry, Discourse don’t let me post two images in a post. So I have to reply second time.

I run

isort.SortImports(file_contents="").place_module("dataclasses")

manually and it still show STDLIB in a venv.

Capture2
Capture2.PNG1086×776 35.3 KB

FIRSTPARTY probably mean proposal from official(?). dataclasses was a proposal library and it add to standard.It can be used in 3.6 by installing as a library for backward compatibility.

12

The pylint executable that you run must belong to the virtualenv as well. If you’re just running “pylint” and pylint is not installed in the virtualenv, you’re probably running whatever you happen to have somewhere else on the system.

It has to be a virtualenv, not a venv. These are different (and competing) products. virtualenv is a 3rd-party package compatible with Py2 and Py3; venv is a standard module that’s Py3.3+-exclusive.

Run the code from my fork and look for discrepancies with Travis’ output, like I did.

13

@native-api

I did not use Python 2 and I don’t know there is a different in virtualenv and venv. It seems like it is a problem in virtualenv instead. Thank you for your assist. I will look for a way to work around it. :kissing_heart:

14

For future reference, I escape vitrualenv and use venv instead which solves the problem.

before_install:
  - deactivate
  - python --version
  - /opt/python/3.7.1/bin/python -m venv ~/venv
  - source ~/venv/bin/activate

Note that you have to use /opt/python. If you use python in vitrualenv, it does not work.

15

I’ve written right in the first message that the problem is in isort and updating it should fix it. If you prefer to never try it and concoct a much more complex workaround… well, whatever works for you.

16

I’ve faced a similar issue but I explicitly use tox which creates its own virtualenvs. I have a feeling that the problem is pyenv and maybe Travis is messing up some env vars too…