-
Notifications
You must be signed in to change notification settings - Fork 516
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
feat: use a local static cache for commonly used contexts #2587
feat: use a local static cache for commonly used contexts #2587
Conversation
Could you explain the mechanics here? I’m trying to see the connection between the locally stored file and the URL. How do we detect changes in the static files — at least at build time? I’m assuming that is a concern. Presumably, any tests would fail the build time tests, which is a pain, but better than failing in a production environment :-). This is good stuff — thanks. |
Of course, sorry for the sparse PR description. In essence, the new loader that replaces the
We don't and this is the pain of having files statically in the build. We'd need to keep contexts up-to-date. I'm not sure this is a big concern given that contexts are supposed to be versioned rather than changed as far as I understand. The medium term solution for aca-py would be to have the document loader be able to pick contexts from some configuration so that the burden of maintaining this list of known contexts is not solely on aca-py maintainers and contributors.
As the files are present within the projects code, build time is unchanged, the only effect is that the package is marginally larger. I might be missing your point here. |
c829eab
to
9998e91
Compare
Thanks for the overview. Let us know when you are happy with this one for a review/merge. Perhaps the “maintenance” question is a GHA that runs either only when triggered or perhaps on a cron job (once a month?) that checks the pre-loaded contexts against the static files and reports an error on a mismatch. It would need a good error message since it will happen so rarely :-). |
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.
I gave this an in depth look, made some very minor adjustments as recommended by pyright, and I'm happy with this. There's opportunity for more sophisticated stuff in the future but I think this gets us more than 90% of the way there.
I wish pyld was a little more... idiomatic python but I don't want to write anything to replace it lol. It does some things that are a little odd, especially next to other code in ACA-Py, but it's not too bad.
@swcurran for the sake of transparency, I'll let you do the honors of merging this PR since I made some small contributions to it. |
I did the merge in the wrong order, so this needs an update to main before it can be merged. Sorry about that. |
Signed-off-by: Clément Humbert <[email protected]>
Signed-off-by: Daniel Bluhm <[email protected]>
Because they make me feel better even though pyld doesn't care lol Signed-off-by: Daniel Bluhm <[email protected]>
814e40f
to
52db475
Compare
Kudos, SonarCloud Quality Gate passed! |
I'll consider this an indication of intent to merge and will go ahead and push the button now that this branch is up to date and tests are passing! |
Related to this issue
StaticCacheJsonLdDownloader
StaticCacheJsonLdDownloader
resolves contexts from local package in priority, then delegates to a downloaderJsonLdDocumentDownloader
andJsonLdDocumentParser
are simply lifted from pyld in a way that decouples downloading and parsing JSON-LD documents.