Investigate adding acquisition metadata to rules, acquisition function builders and the ask tell interface (and possibly elsewhere). This can be used to make acquisition function updates depend on more than just the models and data.
There are at least four approaches here:
Breaking API change to add metadata everywhere. Pros: simple to define new builders. Cons: breaking API change affecting every builder and rule, version bump to 2.0.
Non-breaking change extending existing builder and rule classes. Pros: doesn't break existing code, uses existing classes. Cons: defining metadata-using classes is ugly as it requires overriding two methods not one.
Non-breaking change introducing new builder class. Pros: doesn't break existing code, simple to define new builders. Cons: introduces new classes for this use case (and may require more classes in future such as MetadataGreedyAcquisitionFunctionBuilder)
Do nothing! Pros: no breaking changes, uses existing infrastructure, no unstructured data. Cons: less flexible (though it would be good to find an actual use case that illustrates this).
Since we don't currently have a convincing use case, my vote goes to 4. If we find one then we could consider 1, while perhaps holding off breaking the API until we're ready to do a 2.0 release for other reasons.
Fully backwards compatible: depends
PR checklist
[ ] The quality checks are all passing
[ ] The bug case / new feature is covered by tests
[ ] Any new features are well-documented (in docstrings or notebooks)
Related issue(s)/PRs:
Summary
Investigate adding acquisition metadata to rules, acquisition function builders and the ask tell interface (and possibly elsewhere). This can be used to make acquisition function updates depend on more than just the models and data.
There are at least four approaches here:
Since we don't currently have a convincing use case, my vote goes to 4. If we find one then we could consider 1, while perhaps holding off breaking the API until we're ready to do a 2.0 release for other reasons.
Fully backwards compatible: depends
PR checklist