This project is currently not accepting pull requests from the general public yet.
It is currently being developed by the core developers only.
Chalmers Next Labs AB (CNL) manages and maintains this project on behalf of all contributors.
Tergite is developed on a separate version control system and mirrored on GitHub. If you are reading this on GitHub, then you are looking at a mirror.
The following subsections are only relevant for people that are onboarded on the internal version control system.
Merge requests are the best way to propose changes to the codebase. We use a pattern similar to the GitHub Flow and actively welcome your merge requests.
- Clone the repo and create your branch from
main
. - If you've added code that should be tested, add tests.
- If you've changed APIs, update the documentation. Read the section below on documentation.
- Ensure the test suite passes. Run:
pytest tergite_autocalibration
- Make sure your code lints. This can be done by running:
black tergite_autocalibration --check
- Create the merge request!
Good bug reports can make it way easier for a developer to solve the issue. A good bug report tends to contain:
- A quick summary and/or background
- Provide steps to reproduce the error
- Be specific!
- Give sample code if you can.
- What you expected would happen
- What actually happens
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
Here is one example and another example on how to write a good bug report.
When versioning we follow the format {year}.{month}.{patch_number}
e.g. 2023.12.0
.
Please find out more about versioning in the change log.
Since the GitHub repositories are only mirrors, no GitHub pull requests or GitHub issue/bug reports are looked at. Please get in touch via email [email protected] instead.
Make sure you have conda installed. Alternatively, you could also simply have Python 3.10 installed. Clone the repo and enter its root folder:
git clone [email protected]:tergite/tergite-autocalibration.git
cd tergite-autocalibration
Create the conda environment
conda create -n tac python=3.10 -y
Install dependencies
conda activate tac
pip install -e .
Install the development and test dependencies
pip install poetry
poetry install --with dev,test
Run the CLI help command
acli --help
Please read the respective section in the README.md
Each calibration node goes through the following phases in order:
- compilation
- execution
- post-processing
- redis updating
Datasets are stored in out
.
They can be browsed with the dataset browser:
acli browser --datadir PATH_TO_DATA_DIRECTORY
Documentation is rendered with Quarto.
If you had quarto installed in the previous step you can enter the docs_editable
folder and edit the markdown files.
cd docs_editable
Render the documentation and show a preview in the browser
quarto preview
Now you can edit the files in docs_editable
and the contents in the browser window would update automatically.
If you just want to see the documentation, please open docs/index.html
with your browser.
One of the documentation pages is also
about how to write better documentation.
We do not recommend to make your code having dependencies to proprietary software. If you still need to install proprietary dependencies, please do so by running:
pip install -r requirements_proprietary.txt
Make sure you have ssh access to all proprietary repositories, otherwise the installation will fail.
When you are using imports of proprietary resources in the code, please make sure that they are wrapped with a try
and catch
statement.
try:
from superconducting_qubit_tools.clifford_module.randomized_benchmarking import *
except ImportError:
logger.warning(
"Could not find package: superconducting-qubit-tools.",
"This is a proprietary licenced software.",
"Please make sure that you are having a correct licence and install the dependency",
)
Please try to use proprietary resources only on experimental features and do not integrate them into the default workflows. The scope of the Tergite project is to be as open-source as possible.
When you submit code changes, your submissions are understood to be under the same Apache 2.0 License that covers the project. Feel free to contact the maintainers if that's a concern.
Before you can submit any code, all contributors must sign a contributor license agreement (CLA). By signing a CLA, you're attesting that you are the author of the contribution, and that you're freely contributing it under the terms of the Apache-2.0 license.
The individual CLA document is available for review as a PDF.
Please note that if your contribution is part of your employment or your contribution is the property of your employer, you will also most likely need to sign a corporate CLA.
All signed CLAs are send by email to [email protected].
This document was adapted from a gist by Brian A. Danielak which was originally adapted from the open-source contribution guidelines for Facebook's Draft