-
Notifications
You must be signed in to change notification settings - Fork 51
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: check-in schema generated from higlass_schema #1078
base: develop
Are you sure you want to change the base?
Conversation
Looks good. I didn't go through the schema line by line but it looks like a reasonable addition. A few questions:
https://github.com/higlass/higlass-pileup/blob/master/src/index.html#L61 Do you know if it's possible to do something like subclass a schema? I'm thinking in terms of plugin tracks it would be nice if they could take the existing higlass schema, add whatever they need and then use that? I presume it would just be a matter of subclassing the pydantic class and regenerating the schema? |
I just ran the test suite (sucessfully) locally. I can go through some of the view configs.
I'll try that out.
So I ran into something similar (for different reasons) that I need for We can make the schema generic over different properties, and any concrete subclassing of the generic config will extend the schema. from typing import Literal, Union
from higlass_schema as hgs
class MyCustomTrack(hgs.BaseTrack[Literal["a-custom-track"]):
customField: str = "I'm a custom field"
hgs.Viewconf.schema_json() # base schema, "bounds" on generic types are used to generate schema
# equivalent to
hgs.Viewconf[hgs.View[hgs.Track]].schema_json()
# extended
hgs.Viewconf[hgs.View[Union[hgs.Track, MyCustomTrack]].schema_json() # explicit extension The added benefit here is that we can control which parts of the schema are "extendable" |
Let me know if that makes any sense or if you'd want to hop on a call to discuss anything. |
Yeah, this makes sense. Thank you! I'm thinking that plugin repos could have a small chunk of Python code that extends the schema and higlass-schema and generates their own. Mixing Python and JS is not ideal but as far as I know there's no JS equivalent to pydantic? |
Just opened a PR to add a simple CLI for checking schemas:
In that PR I expanded the Track definition to include TL;DR - with this change, the pile-up schema you shared is valid but all the unrecognized tracks end up being from typing import Union
import higlass_schema as hgs
hgs.Viewconf[
hgs.View[hgs.EnumTrack, hgs.CombinedTrack, hgs.HeatmapTrack]
].parse_file("./pileup.json") # fails because tracks aren't one of enum/combined/heatmaps
c = hgs.Viewconf[
hgs.View[hgs.EnumTrack, hgs.CombinedTrack, hgs.HeatmapTrack, hgs.BaseTrack]
]parse_file("./pileup.json") # success!
track = c.views[0].tracks.top[0] # hgs.BaseTrack
print(track.type) # type == str, "chromosome-labels"
print(track.filetype) # type == Any, "chromsizes-tsv" , not defined on BaseTrack, but additional properties are allowed and will be added to the instance By adding the hgs.Viewconf.parse_file("./pileup.json") # ok! Then in a python library like |
That seems reasonable. By the way, why do you use the name |
I bootstrapped Line 407 in 274ebb2
A track for base higlass is defined as |
ee0592f
to
91d4c1f
Compare
Schema tests had been turned off for a while. Good thing we didn't merge. Need to have a closer look. |
Anything to be done here on my end? |
Nope! I just need to spend some time and look at it. |
Description
The file checked in was generated via:
pip install git+https://github.com/higlass/higlass-schema python -m higlass_schema.main > app/schema.json
If the changes are desirable, we can discuss how to add
higlass_schema
as a dependency to this repo.This PR introduces
schema.json
generated fromhiglass/higlass-schema
. It replaces the old schema with one that is generated automatically from python class definitions.The initial python code was bootstrapped via a code-generation tool which used the
schema.json
from this repo as input. Classes were modified manually to better reflect the types described here.This is a step towards keeping the higlass client and any python API in sync with minimal manual refinement. The idea is that
higlass/higlass-schema
serves as the "source of truth" and schema changes should occur there.Checklist