Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relax grpcio & grpcio-tools version #49

Open
shunter93 opened this issue Nov 8, 2024 · 4 comments
Open

Relax grpcio & grpcio-tools version #49

shunter93 opened this issue Nov 8, 2024 · 4 comments

Comments

@shunter93
Copy link

Evening!

Would it be possible to relax the requirement for grpcio>=1.67.1. It's causing a bunch of conflicts with another in-house library we build and use in our environment, which requires a slightly older version of grpcio (1.65.5).

Getting the following error on import:

RuntimeError: The grpc package installed is at version 1.65.5, but the generated code in saleae/grpc/saleae_pb2_grpc.py depends on grpcio>=1.67.1. Please upgrade your grpc module to grpcio>=1.67.1 or downgrade your generated code using grpcio-tools<=1.65.5.

There's no way to downgrade the grpcio version, as it's specified in the logic2-automation TOML file and the source is built outside of our own pip environment.

There is the following (temporary!) solution:
pip install hatchling (build backend for library)
pip install grpc-tools==1.65.5 (just some older version to prove the point)
pip install linkclient
pip install logic2-automation --no-cache-dir --no-build-isolation

But this won't work for us, as we package up logic2-automation and other libraries in a setup.py file and build a Python wheel for use in other project (and so specifying the additional pip arguments is not possible).

Would you able to help us? The logic2-automation API is absolutely key to our operation, and it won't be a sustainable solution to release a new version of our in-house library every time a new version of grpcio comes out!

Thanks,
Sophie

@timreyes
Copy link

timreyes commented Nov 8, 2024

@shunter93 Thanks for the heads up, and apologies for the trouble with that! I'll get this on the queue to review with the software team. We've got some folks out of office for the long weekend here in the US, however, we'll keep you updated.

@huffman
Copy link
Contributor

huffman commented Nov 13, 2024

@shunter93 Hey there!

Our requirements should be pretty lenient - we specify >=1.13.0 here: https://github.com/saleae/logic2-automation/blob/develop/python/pyproject.toml#L14

I think this is the same issue: #24

I'll spend a little time right now seeing if I can figure out a path forward for this - I'd appreciate any suggestions if you have them!

@shunter93
Copy link
Author

shunter93 commented Nov 14, 2024

Hey @huffman!

Thanks for the quick reply. Looks like it's the exact same issue as #24.

Yeah, it's a tricky one. Setting grpcio>=1.13.0 means it'll take the latest available, so we end up with 1.67.1. This grpcio version is used to dynamically compile logic2-automation. The compile version of grpcio must be <= the run-time version. If there's then another dependency in your environment that requires a lesser version of grpcio, that older version is installed, and you end up with the above error when trying to import logic2-automation.

We've temporarily resolved this by hand-rolling logic2-automation, with grpcio pinned to 1.65.5 and hosting it in our internal PyPi repo. This obviously can't be a permanent solution, as we'd like to be able to pick up new releases from you! But pinning it to a slightly older version of grpcio on your side might be a way forward? Then you're not forcing users to be on the latest version of grpcio!

@huffman
Copy link
Contributor

huffman commented Nov 20, 2024

@shunter93 I'm not actively working on this yet, but wanted to make sure to reply.

But pinning it to a slightly older version of grpcio on your side might be a way forward?

Unfortunately there isn't a single version we can use (as far as I am aware) that is fully forwards compatible. There are specific versions that break compatibility, so there might be a route using extras_require to let the user specify the version they need. Ideally it would be automatic, but maybe this is a reasonable compromise.

I wish I could say we were working on this now, but it's not currently at the top of our priority list. We will definitely get back to it, but I don't currently have a timeline. I'll update here when we do, though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants