Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inconsistent results from isort when used in CI on travis #457

Closed
samuelcolvin opened this issue Aug 7, 2016 · 7 comments
Closed

inconsistent results from isort when used in CI on travis #457

samuelcolvin opened this issue Aug 7, 2016 · 7 comments
Labels
bug Something isn't working

Comments

@samuelcolvin
Copy link

https://travis-ci.org/samuelcolvin/arq/builds/150409550

I'm trying to use isort in CI to make sure import orders are always correct, however I'm getting different results locally and on travis.

In /arq/testing.py isort on travis says there should be a blank link (see build report above), locally it says it's fine.

Both setups are running isort 4.2.5 with python 3.5.

The only difference I can find is that the local version of python is 3.5.0, while on travis it's 3.5.2.

@timothycrosley timothycrosley added the bug Something isn't working label May 11, 2017
@kaedroho
Copy link

kaedroho commented May 26, 2017

Just been debugging this as I've hit this issue on a project I'm working on. It seems to be an issue with the way dependencies are installed. If dependencies are being installed with distutils (aka python setup.py install), some dependencies such as Pillow and BeautifulSoup get detected as "first party" by isort. This is probably because these dependencies use aliases (PIL = Pillow, bs4 = BeautifulSoup) which are handled differently by distutils so isort can't see them in your virtual environment and it assumes they're "first party".

A workaround is to run pip install -e. instead of python setup.py install. If you have caching enabled, don't forget to clear it!

@kaedroho
Copy link

@samuelcolvin The blank line you're getting indicates one of the imports are being detected as a different category to the other. Did you install all dependencies the same way locally as you did on TravisCI?

@kaedroho
Copy link

You can also workaround this by explicitly stating which dependencies are first/third party by using the known_first_party and known_third_party settings.

@timothycrosley
Copy link
Member

timothycrosley commented May 30, 2017

@kaedroho's suggestions are on point, closing this issue for now, as I haven't been able to directly reproduce

Thanks!

~Timothy

@samuelcolvin
Copy link
Author

Sorry not to close this issue sooner, pretty sure the problem was installing the library via pip install -e ... which made it appear "1st party", then installing it normally on travis.

@timothycrosley
Copy link
Member

@samuelcolvin No worries! Glad your issue was resolved :)

@auvipy
Copy link

auvipy commented Sep 26, 2018

facing it on celery project as well. any suggestions?

partmor added a commit to partmor/ezaero that referenced this issue May 12, 2019
In order to overcome inconsistencies between local executions and travis-ci.
E.g. see: PyCQA/isort#457 (comment)
erwanp added a commit to dcmvdbekerom/radis that referenced this issue Jun 26, 2021
(to fix any first/third library problem ? PyCQA/isort#457 )
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants