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

Observations getting 100% test passage using googleapis-common-protos=1.56.4 #2971

Closed
mcg1969 opened this issue Oct 10, 2022 · 3 comments
Closed
Labels
bug Something isn't working

Comments

@mcg1969
Copy link

mcg1969 commented Oct 10, 2022

Describe your environment

  • Python 3.8, 3.9, 3.10
  • linux-64, win-64, osx-64, osx-arm64, linux-aarch64, linux-ppc64le
  • conda packages instead of pip

Steps to reproduce

This multi-output conda recipe

AnacondaRecipes/opentelemetry-python-feedstock#1

is able to build all of the subpackages of opentelementry=1.12.0, even if they are linked against googleapi-common-protos=1.56.4. This is significant because this issue suggests this should not be possible; i.e., that 1.56.2 or earlier should be required. But I've been unable to reproduce the specific issue that is described there. So I'm patching the recipe and the setup.cfg so that 1.56.4 is actually permitted.

Having said that, I also found that I needed to force-pin to backoff<2.0 to get this to work, as discussed here:
#2829

And I also needed to apply this PR as a patch to resolve a test failure:
#2875

I recognize this isn't a typical issue report. But it is my view that the googleapi-common-protos <1.56.3 constraint should be removed from the requirements, and the true root cause of that failure should be determined.

@aabmass
Copy link
Member

aabmass commented Nov 4, 2022

I recognize this isn't a typical issue report. But it is my view that the googleapi-common-protos <1.56.3 constraint should be removed from the requirements, and the true root cause of that failure should be determined.

The logs for the builds linked in that PR are expired so I can't see them but maybe it was related to protocolbuffers/protobuf#10051 in which case we just need to regenerate the jaeger protobuf code? @mcg1969 If you can send a PR to remove the pinned dep (or possibly just exclude the single bad release if it's working now), that would be appreciated.

The other two issues you linked are both fixed as of the most recent release.

@lzchen
Copy link
Contributor

lzchen commented Nov 22, 2022

@mcg1969
Has the above comment addressed your issue?

@mcg1969
Copy link
Author

mcg1969 commented Nov 22, 2022

I don't mind if y'all close this out. I'm likely not going to be able to submit a PR here. I was able to finish my packaging work prior to finishing the report and I simply had to move on to other packages! I'm grateful for the project, truly!

@aabmass aabmass closed this as completed Dec 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants