Open MicaelJarniac opened 1 year ago
This is very low priority, and it's easy enough for users to add this functionality manually, via Nox for example, as I have. The example configuration I showed is basically the one I use to run Ruff on generated code.
I just noticed that when installing betterproto[compiler]
it includes isort
, which is now running on all files in my editor (I have it configured to run whichever linting tools are installed in the virtualenv so it can easily vary by project) and conflicting with ruff
(which I'm using instead of isort
as you are).
Is either ruff
or isort
even needed? Feels like formatting and linting tools shouldn't be a dependency of code generators. It would be pretty hard to predict what tools someone is using and what their settings are. IMO for generated code as long as the code works it doesn't need to look super pretty. I typically tell black, ruff, etc to ignore generated code, but of course you can add it as a post-generate step if you like, as you mentioned you're doing.
I format it myself with a Nox session after the code is generated, so I wouldn't mind if Betterproto didn't format code itself.
In your case, though, I'd suggest installing and running betterproto[compiler]
only in a Nox session, which would keep its dependencies separate from your dev environment, and fix the issue you're having with your editor running isort.
Would you accept a PR that made the formatting optional? That way users can still compile without having to install black and isort and then just run their own formatting after
Maybe the check at https://github.com/danielgtaylor/python-betterproto/blob/1f88b67eeb9871d33da154fd2c859b9d1aed62c1/src/betterproto/plugin/compiler.py#L9-L18 could just be a warning instead of exiting and if either black or isort is not found, they are just not run?
https://beta.ruff.rs
Config example:
It's possible to have it only emulate isort, but I've tried to enable as much as possible from it, which is still incredibly fast.
Can be run as
ruff check --fix
.