Thanks for this interesting workaround. I hadn’t considered that.
I completely understand that from a Django maintainer’s perspective, uniformity is key. However, for a regular developer working on multiple Django projects, each with different formatting requirements, the situation becomes more challenging. Dealing with shims or manipulating the PATH could become cumbersome.
That’s an interesting point. I might have missed something in the DEPs and related discussions, but could you provide some context regarding this promise? Was it specifically about the formatting of the Django codebase, or did it also encompass “user space”?
That would be ideal. However, there’s an issue. The current implementation in Django hardcodes the black --fast command. Since ruff format doesn’t have a --fast option (it’s designed to be fast by default), any shim would need to either adapt to or ignore this parameter. So I doubt that such a shim will ever be provided by the ruff maintainers themselves.
In response, I’d be satisfied with a simple FORMATTER setting, "black --fast" by default, which could be executed as is. It could be also overridden in a hypothetical pyproject.toml section:
[tool.django]
formatter = "ruff format"
Or in settings.py:
FORMATTER = "ruff format"
These options might deviate from the current ideology of tweaking Django’s setup. However, as far as I can see, environment variables are utilized in some parts of the codebase to adjust the behavior of CLI commands, so having it in a .env file or passing it inline (FORMATTER="ruff format" ./manage.py makemigrations) seems legitimate.