qc2
Facilitate the orchestration of quantum chemistry applications on quantum computers
Science Score: 44.0%
This score indicates how likely this project is to be science-related based on various indicators:
-
✓CITATION.cff file
Found CITATION.cff file -
✓codemeta.json file
Found codemeta.json file -
✓.zenodo.json file
Found .zenodo.json file -
○DOI references
-
○Academic publication links
-
○Academic email domains
-
○Institutional organization owner
-
○JOSS paper metadata
-
○Scientific vocabulary similarity
Low similarity (15.1%) to scientific vocabulary
Repository
Facilitate the orchestration of quantum chemistry applications on quantum computers
Basic Info
- Host: GitHub
- Owner: qc2nl
- License: apache-2.0
- Language: Jupyter Notebook
- Default Branch: main
- Homepage: https://qc2.readthedocs.io/
- Size: 16.3 MB
Statistics
- Stars: 3
- Watchers: 2
- Forks: 2
- Open Issues: 23
- Releases: 0
Metadata Files
README.dev.md
qc2 developer documentation
If you're looking for user documentation, go here.
Development install
```shell
Create a virtual environment, e.g. with
python3 -m venv env
activate virtual environment
source env/bin/activate
make sure to have a recent version of pip and setuptools
python3 -m pip install --upgrade pip setuptools
(from the project root directory)
install qc2 as an editable package
python3 -m pip install --no-cache-dir --editable .
install development dependencies
python3 -m pip install --no-cache-dir --editable .[dev] ```
Afterwards check that the install directory is present in the PATH environment variable.
Running the tests
There are two ways to run tests.
The first way requires an activated virtual environment with the development tools installed:
shell
pytest -v
The second is to use tox, which can be installed separately (e.g. with pip install tox), i.e. not necessarily inside the virtual environment you use for installing qc2, but then builds the necessary virtual environments itself by simply running:
shell
tox
Testing with tox allows for keeping the testing environment separate from your development environment.
The development environment will typically accumulate (old) packages during development that interfere with testing; this problem is avoided by testing with tox.
Test coverage
In addition to just running the tests to see if they pass, they can be used for coverage statistics, i.e. to determine how much of the package's code is actually executed during tests. In an activated virtual environment with the development tools installed, inside the package directory, run:
shell
coverage run
This runs tests and stores the result in a .coverage file.
To see the results on the command line, run
shell
coverage report
coverage can also generate output in HTML and other formats; see coverage help for more information.
Running linters locally
For linting we will use prospector and to sort imports we will use isort. Running the linters requires an activated virtual environment with the development tools installed.
```shell
linter
prospector
recursively check import style for the qc2 module only
isort --check-only qc2
recursively check import style for the qc2 module only and show
any proposed changes as a diff
isort --check-only --diff qc2
recursively fix import style for the qc2 module only
isort qc2 ```
To fix readability of your code style you can use yapf.
You can enable automatic linting with prospector and isort on commit by enabling the git hook from .githooks/pre-commit, like so:
shell
git config --local core.hooksPath .githooks
Generating the API docs
shell
cd docs
make html
The documentation will be in docs/_build/html
If you do not have make use
shell
sphinx-build -b html docs docs/_build/html
To find undocumented Python objects run
shell
cd docs
make coverage
cat _build/coverage/python.txt
To test snippets in documentation run
shell
cd docs
make doctest
Versioning
Bumping the version across all files is done with bumpversion, e.g.
shell
bumpversion major
bumpversion minor
bumpversion patch
Making a release
This section describes how to make a release in 3 parts:
- preparation
- making a release on PyPI
- making a release on GitHub
(1/3) Preparation
- Update the
(don't forget to update links at bottom of page) - Verify that the information in
CITATION.cffis correct, and that.zenodo.jsoncontains equivalent data - Make sure the version has been updated.
- Run the unit tests with
pytest -v
(2/3) PyPI
In a new terminal, without an activated virtual environment or an env directory:
```shell
prepare a new directory
cd $(mktemp -d qc2.XXXXXX)
fresh git clone ensures the release has the state of origin/main branch
git clone git@github.com:qc2nl/qc2 .
prepare a clean virtual environment and activate it
python3 -m venv env source env/bin/activate
make sure to have a recent version of pip and setuptools
python3 -m pip install --upgrade pip setuptools
install runtime dependencies and publishing dependencies
python3 -m pip install --no-cache-dir . python3 -m pip install --no-cache-dir .[publishing]
clean up any previously generated artefacts
rm -rf qc2.egg-info rm -rf dist
create the source distribution and the wheel
python3 setup.py sdist bdist_wheel
upload to test pypi instance (requires credentials)
twine upload --repository-url https://test.pypi.org/legacy/ dist/* ```
Visit https://test.pypi.org/project/qc2 and verify that your package was uploaded successfully. Keep the terminal open, we'll need it later.
In a new terminal, without an activated virtual environment or an env directory:
```shell cd $(mktemp -d qc2-test.XXXXXX)
prepare a clean virtual environment and activate it
python3 -m venv env source env/bin/activate
make sure to have a recent version of pip and setuptools
pip install --upgrade pip setuptools
install from test pypi instance:
python3 -m pip -v install --no-cache-dir \ --index-url https://test.pypi.org/simple/ \ --extra-index-url https://pypi.org/simple qc2 ```
Check that the package works as it should when installed from pypitest.
Then upload to pypi.org with:
```shell
Back to the first terminal,
FINAL STEP: upload to PyPI (requires credentials)
twine upload dist/* ```
(3/3) GitHub
Don't forget to also make a release on GitHub. If your repository uses the GitHub-Zenodo integration this will also trigger Zenodo into making a snapshot of your repository and sticking a DOI on it.
Owner
- Name: qc2nl
- Login: qc2nl
- Kind: organization
- Repositories: 1
- Profile: https://github.com/qc2nl
Citation (CITATION.cff)
# YAML 1.2
---
cff-version: "1.2.0"
title: "qc2: Modular Software for Seamless Integration of Quantum Chemistry and Quantum Computing"
- family-names: Renaud
given-names: Nicolas
email: n.renaud@esciencecenter.nl
affiliation: Netherlands eScience Center
orcid: "https://orcid.org/0000-0001-9589-2694"
- family-names: Romero Rocha
given-names: Carlos Murilo
email: c.rocha@esciencecenter.nl
affiliation: Netherlands eScience Center
orcid: "https://orcid.org/0000-0002-4118-8308"
identifiers:
- type: url
value: https://blog.esciencecenter.nl/quantum-computing-for-quantum-chemistry-with-qc2-69ee18ef2969
description: Quantum Computing for Quantum Chemistry with qc2
- type: doi
value: 10.5281/zenodo.14186370
description: Concept DOI for Zenodo deposition
date-released: 2024-11-19
version: "v1.1.3"
repository-code: "git@github.com:qc2nl/qc2"
abstract: >-
qc2 is a modular software designed to seamlessly integrate
traditional computational chemistry codes and quantum computing
frameworks.
keywords:
- quantum computing
- quantum chemistry
message: "If you use this software, please cite it using the metadata from this file."
license: Apache-2.0
GitHub Events
Total
- Create event: 15
- Release event: 2
- Issues event: 10
- Delete event: 7
- Member event: 1
- Issue comment event: 14
- Push event: 61
- Pull request event: 22
- Fork event: 1
Last Year
- Create event: 15
- Release event: 2
- Issues event: 10
- Delete event: 7
- Member event: 1
- Issue comment event: 14
- Push event: 61
- Pull request event: 22
- Fork event: 1
Dependencies
- actions/checkout v4 composite
- conda-incubator/setup-miniconda v3 composite