You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@TomAugspurger kindly pointed out on this PR that we could be using isort for formatting imports and have a standardized approach across the codebase.
I will draft up an initial config based on the rules used in dask-ml and the comments from @jbrockmendel in the above PR. If anyone feels strongly about any of the rules please comment here.
My proposed plan for introducing is we define a config and I run this for a handful of files. ( 1st PR )
We then over the period of a few weeks we encourage developers to run isort over their PRs and we can iron out any issues in the config set up.
Then we introduce a check into our CI build isort --recursive --check-only. And perhaps use this so developers can just run flake8 on their code like before.
Any thoughts/concerns here?
The text was updated successfully, but these errors were encountered:
I don't have any preferences on the style of the imports, beyond separating
stdlib
3rd party
pandas
into three sections.
In the past we've always used absolute imports. I find relative imports slightly nicer to work with. If we want to change to relative, now is the time to do it.
On the process, I think the first step (after agreeing on a config) is to add the isort check to our CI config. We'll need to set the skip setting. At the start this will be a long list of files, but over the course of several PRs we can work that down and maybe eventually eliminate it entirely (there may be some files we don't care about).
@alimcmaster1 if its convenient to configure isort to order pandas-internal imports by dependency structure that'd be great, but don't go too far out of your way. I think I'm the only one who makes a point of it.
@TomAugspurger kindly pointed out on this PR that we could be using isort for formatting imports and have a standardized approach across the codebase.
I will draft up an initial config based on the rules used in dask-ml and the comments from @jbrockmendel in the above PR. If anyone feels strongly about any of the rules please comment here.
My proposed plan for introducing is we define a config and I run this for a handful of files. ( 1st PR )
We then over the period of a few weeks we encourage developers to run isort over their PRs and we can iron out any issues in the config set up.
Then we introduce a check into our CI build
isort --recursive --check-only
. And perhaps use this so developers can just run flake8 on their code like before.Any thoughts/concerns here?
The text was updated successfully, but these errors were encountered: