Make Ruff an optional dependency to avoid upper bound restriction

[johnthagen]

Currently, ruff is listed as a hard dependency of openapi-python-client:

openapi-python-client/pyproject.toml

Line 17 in a73dfd4

"ruff>=0.2,<0.4",

But this means that if a user includes openapi-python-client as their own dev dependency (in order to lock its version with Poetry, for example), they can't upgrade to newer Ruff releases until openapi-python-client does. This is made worse if they need to pin to an older version of openapi-python-client due an incompatibility that arises (e.g., #926).

We need to pin our openapi-python-client rather than using pipx to install it (as recommended in the README), because we need all developers on the team to always get the correct version that we've tested, thus openapi-python-client's dependencies will influence our project's dependencies.

Could ruff be made an extras so that it's optional?

[johnthagen]

I see here why Ruff is a hard dependency: https://github.com/openapi-generators/openapi-python-client?tab=readme-ov-file#installation

Note the --include-deps option makes ruff available in your path so that openapi-python-client can use it to clean up the generated code.

It might be nice to make this optional? I do see the convenience, but for example, on our project we manage Ruff format ourselves as do perhaps others? And then if it were made optional the Ruff version wouldn't need to be restricted by openapi-python-client.

[johnthagen]

So what a lot of projects do in this situation is to make the default recommended way to install the package include all extras, see uvicorn for example:

pip install 'uvicorn[standard]' 

And even the FastAPI docs prescribe this.

Another popular package that does this is psycopg:

pip install "psycopg[binary]" 

This could be a nice middle ground for openapi-python-client, so the README would simply state something like:

To install openapi-python-client with the standard set of features, run:

pip install openapi-python-client[standard] 

That way, when users come to the project, they are always shown a good default experience with all of the tools you would like to support?

[dbanty]

Oh that's a good idea, and we could make it a breaking change so hopefully folks read the changelog and add the features as needed. Would also need to tweak the GitHub Action so that it adds the features automatically, but only for new enough versions of the generator 🤔.

[yyyxam]

Any updates on this? Just stumbled upon this issue myself. I had this project on 0.20.0 as a dependency while my project has the newest Ruff version, which caused a conflict. I updated to 0.21.5, but I shouldn't be forced to IMO

[johnthagen]

@dbanty We just hit this problem again where when we updated our dependencies, Ruff updated to 0.8.x first and then:

 - Downgrading httpx (0.27.2 -> 0.26.0) - Updating ruff (0.7.2 -> 0.8.2) - Downgrading typer (0.12.5 -> 0.9.4) - Downgrading openapi-python-client (0.21.6 -> 0.17.3) 

[johnthagen]

This is also a ongoing discussions to propose a way to define default extras, which would also solve this problem if the proposal is accepted and implemented

• https://discuss.python.org/t/adding-a-default-extra-require-environment/4898/174

[dbanty]

I know it's not as good as optional, but starting with 0.27 there will be no upper bound of Ruff anymore, since I think I reduced the risk of generation breaking on every major version of Ruff.

If we can get the Jinja templates into a nice enough state that the code they create is tolerable without Ruff, I will make it optional. Easier said than done, though, since whitespace is extra hard with those 😓

[johnthagen]

@dbanty I think this is a very pragmatic move and I appreciate the careful consideration of trade offs you are taking.