workbench_algorithms.experimental

Subpackage for experimental WBA functions and Qubricks.

This directory is designed to allow for free-form experimentation and prototyping while keeping core development constrained to the WBA repo. The idea is that new interfaces, refactors or otherwise experimental Qubricks will be implemented here, to be imported as from workbench_algorithms.experimental import ... so that they can be used by other developers without them having to align disparate branches (that may have become stale).

NOTES FOR USERS: - The code contained within this directory should be considered unstable and subject to breaking changes. It should be used with appropriate caution. - Code implemented here may have less documentation than code implemented in the main package, and may also have more uncaught bugs. - The organization of the code in this subpackage is designed to mimic that of the main WBA package - so where in WBA you might have from workbench_algorithms.subroutines import x, here you would do from workbench_algorithms experimental.subroutines import x.

NOTES FOR DEVELOPERS: - Experimental code will have a relaxed, but not totally eliminated, set of requirements to be merged. Specifically: - Code is still expected to be tested, but requirements won't be as robust as for the main branch (i.e. if the main functionality works on expected inputs, this should be sufficient) - Documentation requirements will be relaxed - docstrings and usage notebooks are still recommended to make usage clearer, but robust documentation will not be enforced. - Breaking changes can be made to experimental interfaces without requiring a major version bump, but devs should be conscious of the effects on users of doing so - if you're implementing a number of alternative APIs to choose from, consider using versioning as MyAPIV1, MyAPIV2 to minimise churn - Code merged into experimental should be considered as transient and short-lived. It should either be merged into the main repo once the API is stabilized or deleted if the feature is not needed. - MRs are still subject to review, but we should err a little more on the side of rapid development rather than robust checks.