Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Make Ruff an optional dependency to avoid upper bound restriction#998

johnthagen started this conversation inGeneral
Discussion options

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

But this means that if a user includesopenapi-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 untilopenapi-python-client does. This is made worse if they need to pin to an older version ofopenapi-python-client due an incompatibility that arises (e.g.,#926).

We need to pin ouropenapi-python-client rather than usingpipx 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, thusopenapi-python-client's dependencies will influence our project's dependencies.

Couldruff be made anextras so that it's optional?

You must be logged in to vote

Replies: 2 comments 8 replies

Comment options

johnthagen
Mar 12, 2024
Collaborator Author

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 byopenapi-python-client.

You must be logged in to vote
7 replies
@johnthagen
Comment options

johnthagenMar 12, 2024
Collaborator Author

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

pip install 'uvicorn[standard]'

And even theFastAPI docs prescribe this.

Another popular package that does this ispsycopg:

pip install "psycopg[binary]"

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

To installopenapi-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
Comment options

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
Comment options

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
Comment options

johnthagenDec 9, 2024
Collaborator Author

@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
Comment options

johnthagenJan 9, 2025
Collaborator Author

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

Comment options

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 tolerablewithout Ruff, I will make it optional. Easier said than done, though, since whitespace is extra hard with those 😓

You must be logged in to vote
1 reply
@johnthagen
Comment options

johnthagenOct 28, 2025
Collaborator Author

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

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
General
Labels
None yet
3 participants
@johnthagen@dbanty@yyyxam

[8]ページ先頭

©2009-2025 Movatter.jp