pyhf
pyhf copied to clipboard
store tests in a jsonnet library
Description
A nice way to store spec templates is to use jsonnet https://github.com/google/jsonnet
I added this here as a demo for the tests, but actually I was thinking maybe we could use this in the CLI as well
this works
cat << EOF| jsonnet - --ext-code-file templates=validation/templates.libsonnet|pyhf cls
std.extVar("templates").simple {
source:: { bindata: {
sig: [10], bkg: [50], data: [51]
}}
}
EOF
e.g. the tempates in pyhf.simplemodels could acutally be jsonnet templates
related to #264
Checklist Before Requesting Reviewer
- [ ] Tests are passing
- [ ] "WIP" removed from the title of the pull request
- [ ] Selected an Assignee for the PR to be responsible for the log summary
Before Merging
For the PR Assignees:
- [ ] Summarize commit messages into a comprehensive review of the PR
Coverage decreased (-45.3%) to 53.024% when pulling f48a1e500deed65f009d4d4e464fea0dff74bfcf on tests/declarative_validation_data into d470ae07145e53d7dc270e31fbdb6e479e09ed38 on master.
Are we saving a lot of extra code with the addition of another library here? It almost looks 1-1. It's not clear to me if we benefit strongly from this now, or if we switch to this now because it will pay off in the future.
@kratsg where we save is that jsonnet is a turing complete templating language we do not need to build. i.e. the complexity of the templates right now is low, but however complex they become, we can be confident that we can express it in jsonnet without managing any code ourselves
a benefit now is that we can have the template as a data artifact that we can rereference, i.e. in a spec
tests:
- name: test1
source: ...
template_name: simple
the laternative would be to have templates be python
cat templates.py
templates['simple'] = lambda source: {
...
}
------
from .templates import templates
templates['simple'](json.load(open(...)))
functions which I think is not as nice (i.e. I'd rather distribute a template file via a resource pkg_resources.resource_filename('templates.libsonnet') than as code) since this more clearly delienates what is pyhf and what are templates.. also opens up the opportunity to have other people come with their own template libraries distributed as simple files
I understand the hestiation to add a new dep, so I would first only keep it to the dev environment.. if we decide to add it to pyhf proper, then probably as a extra pip install pyhf[templates]
I still want to see something like this happen, to be honest.