-
Notifications
You must be signed in to change notification settings - Fork 84
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: HiFa v1.1.0 schema development #1978
base: main
Are you sure you want to change the base?
Conversation
It's going into the next release though. I don't know if we want to start juggling development HiFa v1.0.0 and v1.1.0 at the same time? But this will need to go in, so that we can deal with multiple schema versions. |
Okay, then I've switched it to be v0.8.0. After the issues with getting v0.7.0 out and also accepting PRs I think it makes sense (for me to figure out how to do release branches) to start using patch releases for when we actually have a bug we need to go back and patch and start having other releases be minor (until we hit v1.0.0). |
Codecov ReportBase: 98.30% // Head: 98.30% // No change to project coverage 👍
Additional details and impacted files@@ Coverage Diff @@
## main #1978 +/- ##
=======================================
Coverage 98.30% 98.30%
=======================================
Files 69 69
Lines 4531 4531
Branches 645 645
=======================================
Hits 4454 4454
Misses 45 45
Partials 32 32
Flags with carried forward coverage won't be shown. Click here to find out more. Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
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 @kratsg for this nice work. Overall this looks good. 👍
I've added a question and some small formatting suggestions, but as we need to fix up the coverage thing I could add those in this weekend once I am at CERN so that you don't waste time having to poke at coverage
's decisions. It is probably faster to locally run
$ nox --session tests --python 3.10 -- coverage
$ nox --session coverage
$ xdg-open ./htmlcov/index.html
to debug coverage than to have GHA do all of that and then have Codecov report it back to us.
If you can also fill out the PR body with some additional context that would be helpful, given that you've done a lot of nice work here (I can also summarize this later, but am not able to succinctly do so now given a lot was added to support this).
class Upgrade_1_0_1: | ||
""" | ||
Used for testing functionality of upgrade. | ||
""" | ||
|
||
version: SchemaVersion = '1.0.1' |
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.
class Upgrade_1_0_1: | |
""" | |
Used for testing functionality of upgrade. | |
""" | |
version: SchemaVersion = '1.0.1' | |
class Upgrade(version: SchemaVersion = "1.0.1"): | |
""" | |
Used for testing functionality of upgrade. | |
""" |
Maybe I'm missing something about what the purpose of upgrader
is, but is there a reason why we need to make this class schema v1.0.1
hardcoded?
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.
We need an Upgrade_X_Y_Z
class for every single version we plan to support upgrading to. When we add a new version of the spec, we have to have a new upgrade class that knows how to upgrade from an old version to the version the class represents.
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.
@kratsg Ah okay, so the real reason is that we can't deterministically know what version we're upgrading from in advance?
Do we have a plan for how to handle upgrading multiple versions in one go? e.g. Let's say we have v1.0.0
, v1.1.0
, v1.2.0, and
v2.0.0. If at this point someone comes along with a
v1.0.0schema and wants to move from
v1.0.0to
v2.0.0` what's the plan for doing this?
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 have ideas on how to do this with python's mro
def upgrade(*, to_version: SchemaVersion | None = None) -> type[UpgradeProtocol]: | ||
if to_version is None or to_version == '1.0.1': | ||
return Upgrade_1_0_1 |
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.
def upgrade(*, to_version: SchemaVersion | None = None) -> type[UpgradeProtocol]: | |
if to_version is None or to_version == '1.0.1': | |
return Upgrade_1_0_1 | |
def upgrade(*, to_version: SchemaVersion | None = None) -> type[UpgradeProtocol]: | |
if to_version is None or to_version == "1.0.1": | |
return Upgrade("1.0.1") |
Follow up to the above.
(Ignore the docs failing as this is Springer's fault: https://twitter.com/HEPfeickert/status/1600915112403304449?s=20&t=kjTW5TNbU_Jukxb0ALd0uQ. We can either fix this up locally in another PR or just wait for them to fix it.) |
d22e37d
to
4e144d7
Compare
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.
@kratsg sorry just a few more questions to help me understand this better. As this will go in this weekend can I also ask you sometime before Monday to write up a summary in the PR body and the squash and merge summary commit? This is a huge amount of work (:bow:) and I want to make sure that we have a summary of this as I think if I had to try to sit down and reread all of this again late at night I might be pressed to do so without some accompanying text.
class Upgrade_1_0_1: | ||
""" | ||
Used for testing functionality of upgrade. | ||
""" | ||
|
||
version: SchemaVersion = '1.0.1' |
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.
@kratsg Ah okay, so the real reason is that we can't deterministically know what version we're upgrading from in advance?
Do we have a plan for how to handle upgrading multiple versions in one go? e.g. Let's say we have v1.0.0
, v1.1.0
, v1.2.0, and
v2.0.0. If at this point someone comes along with a
v1.0.0schema and wants to move from
v1.0.0to
v2.0.0` what's the plan for doing this?
@@ -453,6 +453,7 @@ def test_combine_workspace_incompatible_poi(workspace_factory, join): | |||
def test_combine_workspace_diff_version(workspace_factory, join): | |||
ws = workspace_factory() | |||
ws.version = '1.0.0' | |||
ws['version'] = '1.0.0' |
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'm probably missing the point of this test, but if you put a breakpoint
just after ws = workspace_factory()
(Pdb) ws.version
'1.0.0'
(Pdb) ws["version"]
'1.0.0'
so is the reason to explicitly set this a means to solidify the versions that will be used in the future?
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.
This is just a test to enforce absolutely different versions.
4b061d7
to
178b3db
Compare
178b3db
to
3a3f3a8
Compare
This reverts commit 0f10984.
3a3f3a8
to
531e0ba
Compare
Pull Request Description
The following is happening:
pyhf
to support in the current implementationpyhf.schema
To-Do:
nbconvert
does (see my comment below feat: HiFa v1.1.0 schema development #1978 (comment))pyhf.schema.versions
topyhf.schema.version
depending...)Schema updates:
Checklist Before Requesting Reviewer
Before Merging
For the PR Assignees: