black: Inconsistent performance between GitHub CI and local
Hi there! We’re using black for snakemake (I love it so far!) but I’m running into an issue where, despite having the same version of black installed via conda in GitHub CI versus locally, the local version reports that all is well, the GitHub CI version reports that one file needs to be reformatted. Locally:
$ black --check snakemake tests/*.py
All done! ✨ 🍰 ✨
51 files would be left unchanged.
$ black --version
black, version 19.3b0
and in GitHub CI
Check formatting6s
##[error]Process completed with exit code 1.
Run export PATH="/usr/share/miniconda/bin:$PATH"
export PATH="/usr/share/miniconda/bin:$PATH"
source activate black
black --check snakemake tests/*.py
shell: /bin/bash -e {0}
would reformat /home/runner/work/snakemake/snakemake/snakemake/dag.py
All done! 💥 💔 💥
1 file would be reformatted, 50 files would be left unchanged.
##[error]Process completed with exit code 1.
The version of black there is also the same
black pkgs/main/noarch::black-19.3b0-py_0
Further, locally it tells me I need to reformat other files (which the remote doesn’t suggest)
would reformat /home/vanessa/Documents/Dropbox/Code/Python/snakemake/snakemake/remote/FTP.py
would reformat /home/vanessa/Documents/Dropbox/Code/Python/snakemake/snakemake/remote/HTTP.py
Oh no! 💥 💔 💥
2 files would be reformatted, 49 files would be left unchanged.
Do you have suggestions for what we might further try, or ideas for why it’s inconsistent? The testing step is here (not sure if you can see it) and the PR in question is here. Thanks!
Expected behavior A clear and concise description of what you expected to happen.
The local and remote black formatting commands would produce the same result.
Environment (please complete the following information):
- Version: black, version 19.3b0
- OS and Python version: Linux/Python 3.7.3 locally, Linux/Python 3.7.5 remote.
Does this bug also happen on master? To answer this, you have two options:
Yes I tried this, same result locally. Thanks for your help!
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 14
- Comments: 29
I ran into the same issue because I thought I was using the same version. It turns out that stating the version in tag is not enough. Without specifying it using
version, it defaults to the latest release. check out their doc for ci.I said I’d change this, but I never even opened an issue. I’ll fix that.
accepting
- uses: psf/black@21.9b0in the yaml is very confusing if it doesnt actually run in that version.comment by @JunranY fixed it for me; have to make the version explicit on a seperate line
version: "21.9b0"to actually make it run in a custom version.I ran into this issue as well using the system black package on Ubuntu 20.04. There were wild differences between my mac version and ubuntu in terms of which files should be reformatted. For now I just worked around it by using the pip package version which should be consistent across platforms.
Example:
This might have something to do with how ubuntu builds it’s version of black and not an inconsistency problem on the part of black.
--diffI am running into this and have confirmed that I am nominally running the same version of
blackboth locally and in CI. I will post a minimum working example, once I deal with the issues this has caused.@srinathganesh did you compare the version of black on your host vs. CI? That’s usually the issue - see the above thread for examples to pin to a specific version.
I just encountered this issue with Github Actions, and solved it by fixing my version control of
black.setup.pyexplicitly statedblack==19.10b0setup.py.