-
Notifications
You must be signed in to change notification settings - Fork 550
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
docs: describe annotations
attr of pip_parse
#1667
docs: describe annotations
attr of pip_parse
#1667
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Perhaps try again today? I didn't see any server errors when I triggered it to re-run; just the usual "person hasn't signed CLA" error. There isn't a CLA record for It looks like your profile is marked pretty private ? Perhaps this requirement is what's tripping it up:
|
This Pull Request has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. |
1a1b67e
to
c160c9f
Compare
I tried every couple of weeks and eventually gave up, but today I logged in and it magically worked!
I don't think it was this specific setting, but it was probably some other similar privacy setting that I've since relaxed! Not sure how to un-mark this as stale but I rebased it and looks like the docs update would still be valuable, but let me know if I should change it at all! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
My default expectation would be that the keys to the
annotations
dictionary passed topip_parse
would use thenormalize_name(...)
convention, as is used elsewhere in the API. However, this does not appear to be the case. I originally was going to file a bug, but maybe just documenting the current behavior is enough?For a minimal repro showing that this capitalization is indeed required, see https://github.com/bruno-digitbio/bug-rules-python-annotation-pyqt
In that repo,
will both show
# A comment
at the bottom, as requested in theWORKSPACE
file. However, if you first runthen the auto-generated requirements file will use lowercase for the requirement specification, breaking the desired behavior.
Please let me know if it makes more sense to just check in the docs, include this example (or something similar) as a small test, or something else. Apologies if I missed anything in the contribution guidelines!