-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Fix handling of create_git_blob
's result
#2122
Conversation
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
:( |
@sfdye would you mind taking a look and e.g. reopening this PR? It still seems to be an issue in the current master, which makes using |
Codecov ReportPatch coverage:
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. Additional details and impacted files@@ Coverage Diff @@
## master #2122 +/- ##
==========================================
+ Coverage 98.68% 98.77% +0.08%
==========================================
Files 117 117
Lines 11825 11674 -151
==========================================
- Hits 11670 11531 -139
+ Misses 155 143 -12
☔ View full report in Codecov by Sentry. |
Ah crap I updated using a merge commit, I'll have to fix that up, sorry about the noise. |
ok should be good now. |
`create_git_blob` does not actually return the entire blob object content, per the OpenAPI description it only returns a `short-blob` with the `sha` and `url` properties whereas a "full" blob also has `encoding`, `content`, and `size` (and `node_id` but that's not relevant). Fix by marking the `GitBlob` returned as non-complete, this way normal completion will fetch the additional data iff it is accessed.
create_git_blob
does not actually return the entire blob object content, per the OpenAPI description it only returns ashort-blob
with thesha
andurl
properties whereas a "full" blob also hasencoding
,content
, andsize
(andnode_id
but that's not usually relevant).Fix by marking the
GitBlob
returned as non-complete, this way normal completion will fetch the additional data iff it is accessed.However testing github's behaviour raises a few more questions here:
testCreateGitBlob
specifies thelatin1
encoding, per github's documentation that's not actually supported but apparently github simply treats anything other than"base64"
as"utf-8"
, which is really "text": the json string gets encoded to utf-8 and stored as-is in the blob. So that test's encoding is really misleading.I figure the interface could be improved there, but it's not entirely clear to me whether
PyGithub
is to provide a shallow Python interface to Github or possibly a more high-level one e.g. one could imagine a design wherecreate_git_blob
would automatically select between encoding depending on the input type (str
|bytes
) thus making the explicit encoding unnecessary, the encoding could also be an Enum and default to text-equivalent ("utf-8"
) with base64 being opt-in.An other annoyance with the interface is it looks like github always returns base64-encoded content, again depending on the suitability of higher-level API
GitBlob
could have a utility property handling that automatically rather than requiring the user be aware of the issue.