Repodata API #20
Repodata API #20
Conversation
schuylermartin45
requested review from
markan,
cbouss,
Arishamays1 and
akabanovs
| sha256: str | ||
| name: str | ||
| size: int | ||
| version: str |
There was a problem hiding this comment.
I appreciate that you are deferring parsing the version here.
| repodata_version: int | ||
|
|
||
|
|
||
| _REPODATA_JSON_SCHEMA: Final[SchemaType] = { |
There was a problem hiding this comment.
Is this derived from https://github.com/conda/schemas?
There was a problem hiding this comment.
Don't know how I missed this comment initially. No it isn't, I didn't know this existed. I reverse engineered this schema from examples and then ran an automated test against multiple real world examples.
There is a new schema in the latest code for channeldata.json but I only validate the subdirs field I use to look-up supported architectures.
|
|
||
|
|
||
| @dataclass | ||
| class Repodata: |
There was a problem hiding this comment.
So this seems to be something similar to the Repodata class in anaconda-channel-scanner. The only difference is that there are more checks in this implementation, and that it processes all the info. Anaconda-channel-scanner just reads what it needs for the dependency analysis and also structures the package data into a few levels: package-name/python-version/package-version/build-number. Although I was going to add a way to serialise it too.
There was a problem hiding this comment.
Good to know. For Mark's needs (and I think percy's as well), all the data needs to be available at once. I wanted to create some more intelligent caching setup, but it also sounds like Cheng is on the warpath to replace these unscalable JSON files with something else.
So this is more of a stop-gap until we know what the "new and improved" version will be.
schuylermartin45
force-pushed
the
smartin_repodata_api
branch
2 times, most recently
from
259b2e0
to
e80a236
Compare
- Minor changes to how the `ApiException` classes are maintained
- This will be useful for multiple applications for us.
- Also fixes static analyzer and linter issues
- Breaks out code that can be common to other API implementations - Rearranges the unit tests accordingly. - General updates to our latest style choices
- Clients can use 1 function to request a serialized version of a target `repodata.json` file - Adds unit test coverage - Increase unit test coverage minimum to a final target of 80%
- This should allow for all equivalency comparisons between two `PackageData` objects by `version` and `build_number` - Adds unit tests - Adds `TODO` remarks to add type-checks back in when changes have been made to `conda`
- Adds coverage around `==` and `gt` as sanity checks
- Channel/Architecture data is no longer being provided by a hard-coded mapping and is instead being pulled from a remote source - Fixes type in the Makefile - Adds unit testing
schuylermartin45
force-pushed
the
smartin_repodata_api
branch
from
e80a236
to
37c132e
Compare
|
Marek made me realize on another PR yesterday that I accidentally duplicated myself by not getting this in sooner. So I'm going to merge this so we don't lose track of the rest of this good work. |
@akabanovs @cbouss Adding you both for visibility. You two shouldn't feel required to review this one, unless you want to.
First pass at a new Repodata API that is type-safe and validates the JSON we pull in.
Also allows for easier version-ordering comparisons between two packages. This uses the
VersionOrderclass fromcondaand ALSO compares against thebuild_numberwe pulled from therepodata.jsonfile.