-
Notifications
You must be signed in to change notification settings - Fork 7k
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
add ufmt
as code formatter
#4384
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sweet, thanks @pmeier ! I made a quick pass, the strategy sounds good.
Do we know when the ufmt release will be out?
torchvision/ops/poolers.py
Outdated
@@ -2,7 +2,7 @@ | |||
from torch import nn, Tensor | |||
|
|||
import torchvision | |||
from torchvision.ops import roi_align | |||
from .roi_align import roi_align |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just curious, was this flagged somehow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #4178 (comment). In short: we relied on a specific order of the imports due to a naming conflict. Without this fix we need to exclude these imports from being sorted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There might have been a reason for that initially, but I'm wondering why we even use absolute imports within the torchvision
package. Every torchvision improt should be relative there. Perhaps @fmassa knows?
(anyway, this is for another PR, let's leave it as is :) )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps because absolute import is recommended by PEP8?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The lint workflow is failing, because the version of ufmt
that we need. Otherwise this should be good to go.
@NicolasHug: in #4178 we talked about adding pre-commit hooks for this. I have a PR up that adds this to ufmt
: omnilib/ufmt#15. Since they are not necessary to run ufmt
, IMO we can add them in the future.
pyproject.toml
Outdated
local_utils = [ | ||
"_utils_internal", | ||
"common_utils", | ||
"dataset_utils", | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are local utilities in our test/
folder. Since its not a package, i.e. tests/__init__.py
is missing, usort
does not pick up on the fact that these are local dependencies and sorts them into the third party category.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add this comment in the file to provide context for future us :)
Also to avoid conflicting it with other utils, can we change the name to local_test_utils
? Alternatively we could just add these into the "first-party" category?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively we could just add these into the "first-party" category?
We could, but if you don't have a strong opinion about this, I would leave them in an extra category. IMO, first party and local should be separated, because the latter indicates that this cannot be import the "normal" way. In fact, isort
has a section for local imports where all the relative imports go. Unfortunately, usort
does not have that. I've asked about it in facebook/usort#30.
ignore = E203, E402, W503, W504, F821 | ||
per-file-ignores = | ||
__init__.py: F401, F403, F405 | ||
./hubconf.py: F401 | ||
torchvision/models/mobilenet.py: F401, F403 | ||
torchvision/models/quantization/mobilenet.py: F401, F403 | ||
test/smoke_test.py: F401 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #4178 (comment) for details on this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @pmeier
@NicolasHug: in #4178 we talked about adding pre-commit hooks for this. I have a PR up that adds this to ufmt: omnilib/ufmt#15. Since they are not necessary to run ufmt, IMO we can add them in the future.
I'm a bit confused, do we need pre-commit hooks in the ufmt repo in order to have pre-commit hooks in torchvision?
pyproject.toml
Outdated
local_utils = [ | ||
"_utils_internal", | ||
"common_utils", | ||
"dataset_utils", | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add this comment in the file to provide context for future us :)
Also to avoid conflicting it with other utils, can we change the name to local_test_utils
? Alternatively we could just add these into the "first-party" category?
torchvision/ops/poolers.py
Outdated
@@ -2,7 +2,7 @@ | |||
from torch import nn, Tensor | |||
|
|||
import torchvision | |||
from torchvision.ops import roi_align | |||
from .roi_align import roi_align |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There might have been a reason for that initially, but I'm wondering why we even use absolute imports within the torchvision
package. Every torchvision improt should be relative there. Perhaps @fmassa knows?
(anyway, this is for another PR, let's leave it as is :) )
Just to be sure: we are talking about hooks added by the If yes, we don't need
|
Oh OK, thanks. I didn't know the "upstream" repo (ufmt) had to be configured as well for commit hooks to work. I feel like we might want to wait for commit hooks to be available though. It will probably make the transition smoother for most contributors / developers, and we will just be able to run |
@NicolasHug I've added support for |
Blocked by omnilib/ufmt#13 and omnilib/ufmt#15. After these PRs are in we also need to wait for the next release, which I'm hoping will be quick, since we added some important functionality. |
The PRs I sent to Since this PR will touch (almost?) any |
If you are reading this, you were probably prompted to fix the code format of your PR. Here is what you do: $ git checkout main
$ git pull
$ git checkout $MY_FEATURE_BRANCH
$ git merge -X ours main
$ pre-commit run --all-files
$ git commit -am "fix code format"
$ git push If you don't have |
|
||
|
||
PYTHON_VERSIONS = ["3.6", "3.7", "3.8", "3.9"] | ||
|
||
RC_PATTERN = r"/v[0-9]+(\.[0-9]+)*-rc[0-9]+/" | ||
|
||
|
||
def build_workflows(prefix='', filter_branch=None, upload=False, indentation=6, windows_latest_only=False): | ||
def build_workflows(prefix="", filter_branch=None, upload=False, indentation=6, windows_latest_only=False): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the a way to configure ufmt to avoid making this ' -> "
change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, using double quotes is black's convention
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
black
is the tool doing this. If we don't want it, we could put a skip_string_normalization = true
line into its section in the pyproject.toml
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel this is adding a number of unnecessary changes, given pep8 doesn't recommend one over the other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately this isn't something we can change, as the internal arc lint
would force these back to double quotes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we were not using the default internal linter. Can't we configure that the same way as pointed above by Philip?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's possible, but even if it were I wouldn't recommend it. It's better to stick to the usual convention as much as possible. The only one we don't properly respect is the line length, for historical reasons. Are you mostly concerned about git blame noise?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have the following concerns here:
- Unnecessary changes.
- I am not convinced with the idea of forcing
"
over'
. This should be a user choice given that pep8 doesn't recommend either. Also, this is not the usual convention. Line length is something recommend by pep8. - Python by default uses
'
for representing string:
>>> a = "abc"
>>> a
'abc'
'
uses 1 key stroke against 2 for"
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
regarding 4, you're free to use single quotes if you want and let black
automatically format them :)
For the rest, I understand your point, but one of the goal of using black
is precisely to avoid that kind of discussion about style preferences. It may not be perfect and suit everyone's taste (it doesn't suit mine either), but at least it's a standard that we can all automatically comply to.
Sync is looking good now (it should look like D31379666 and the few diffs below). I'll merge this when green. We can address the flake8 issues later, they're almost all unused imports |
Tests are green. Let's get this in. |
Hey @NicolasHug! You merged this PR, but no labels were added. |
A million thanks to you @pmeier for your help |
Summary: * add ufmt as code formatter * cleanup * quote ufmt requirement * split imports into more groups * regenerate circleci config * fix CI * clarify local testing utils section * use ufmt pre-commit hook * split relative imports into local category * Revert "split relative imports into local category" This reverts commit f2e224c. * pin black and usort dependencies * fix local test utils detection * fix ufmt rev * add reference utils to local category * fix usort config * remove custom categories sorting * Run pre-commit without fixing flake8 * got a double import in merge Reviewed By: kazhang Differential Revision: D31380329 fbshipit-source-id: c1ee3a57589401d88877201fbf40cc968681b640 Co-authored-by: Nicolas Hug <nicolashug@fb.com>
* add ufmt as code formatter * cleanup * quote ufmt requirement * split imports into more groups * regenerate circleci config * fix CI * clarify local testing utils section * use ufmt pre-commit hook * split relative imports into local category * Revert "split relative imports into local category" This reverts commit f2e224c. * pin black and usort dependencies * fix local test utils detection * fix ufmt rev * add reference utils to local category * fix usort config * remove custom categories sorting * Run pre-commit without fixing flake8 * got a double import in merge Co-authored-by: Nicolas Hug <nicolashug@fb.com>
* add ufmt as code formatter * cleanup * quote ufmt requirement * split imports into more groups * regenerate circleci config * fix CI * clarify local testing utils section * use ufmt pre-commit hook * split relative imports into local category * Revert "split relative imports into local category" This reverts commit f2e224c. * pin black and usort dependencies * fix local test utils detection * fix ufmt rev * add reference utils to local category * fix usort config * remove custom categories sorting * Run pre-commit without fixing flake8 * got a double import in merge Co-authored-by: Nicolas Hug <nicolashug@fb.com>
Supersedes #4178. Instead of using
isort
andblack
individually,ufmt
usesusort
andblack
in an atomic way.To keep this PR reviewable, I'm only going to pull the trigger on all formatting changes if the PR is approved otherwise.
This PR is blocked for now until
ufmt>=1.3
is released.