Hi Saleae Team,
First of all I use Logic 2 with the Logic2-automation python package for testing at my job, and It’s generally great to work with, so kudos and thank you for a good tool!
At my job we have a collective test repository using uv for version management. Somehow whenever grpcio releases a new version of their python module, we see an error coming from the logic2-automation when building the virtual environment or importing the package when running a test.
This causes noise as users(there are many) of our test repository are forced to perform a random .lock file update to get their tests to work whenever grpcio releases a new package, even though no changes has been made to the dependencies .toml or .lock file. Maybe you are familiar with this kind of issue?
I tried creating a small demo uv repository with only logic2-automation and I’ve noticed that the file .venv\Lib\site-packages\saleae\grpc\saleae_pb2_grpc.py is not always updating when a new .lock file has been made. even if the .venv folder gets deleted and recreated with uv sync. That could be critical as it contains a demand for a specific grpcio version. I can generate the error this way but I don’t know if this is the root cause of it all.
I hope you can help us out.
Kind regards
Andreas
@aschulz Thanks for reaching out! I’m personally not familiar with this issue / use case, however, I’ll get this on the backlog for our software team to review.
1 Like
Thank you! 
I will just add my thought to this that i find it a bit curious that Logic2-automation can ask specifically for a grpcio package version that is only days old, when the Logic2-automation package itself is a year and a half old.
I don’t know enough about average python package management to have a critical opinion whether that’s normal or not, but it does seem to me something that would make users attempt at overall package version control a difficult task.
These are just my thoughts.
Is this the error that asks you to –force-reinstall? Are these major / backwards-incompatible grpcio updates? I have no idea why it would be trying to auto update, this is the first time I’ve heard of this happening. If you can share your minimal repro that would be helpful.
We do have general issues around matching grpcio/protobuf versions. I’m spending some time looking into solutions right now.
Hi, yes it asks me to pip install logic2-automation –force-reinstall
I’m sending my simple repo that i just build with uv using this guide: Working on projects | uv
If you are unfamiliar with uv repositories, my repo has a main.py file you can run using uv run main.py from the uv-demo folder.
You can specify project dependencies in the pyproject.toml file. If a package is written with no version specified, it will use the newest. When you run command: uv lock --upgrade the exact package dependencies and sub-dependencies will be resolved, based on the pyproject.toml file, and written into the uv.lock file.
With a uv.lock file you can build the virtual environment with the command: uv sync which creates/updates the .venv folder.
The problem is that the file .venv\Lib\site-packages\saleae\grpc\saleae_pb2_grpc.py does not entirely seem to update based on what the uv.lock file dictates.
If the grpcio package that was build is specified to a version lower than .venv\Lib\site-packages\saleae\grpc\saleae_pb2_grpc.py line:8 it will throw the error.
If you download my repo, you should be able to reproduce the error by opening a console in the main folder and run:
pip install uv (if you dont have uv installed)
uv run main.py
uv-demo.zip (29.1 KB)
Hi @aschulz,
Thanks for sending all that over! We were able to reproduce the issue.
Originally grpcio-tools was a runtime dependency of our package, which meant it was affected by any protobuf/grpcio dependencies a project might already have.
We later moved the grpcio-tools dependency from a runtime to a build-time dependency. From what we can tell, this change caused the dependency to no longer be affected by the runtime dependencies, causing it to always use the latest version of grpcio-tools.
Our plan is to make it a runtime dependency again, add tests for these various scenarios and upgrade paths, and add documentation for some of the edge cases users were seeing which led up to this change.
Anyway, that’s just some background. Any other thoughts or feedback would be appreciated.
Ryan
1 Like