solar-wavelength-calibration
A package for matching an observed solar spectrum to a reference solar atlas in order to produce a mapping from raw pixel index to an absolute wavelength value. Please see the online docs for detailed information.
Installation
pip install solar-wavelength-calibration
Development
The source repository can be cloned from BitBucket with the following command
git clone git@bitbucket.org:dkistdc/solar-wavelength-calibration.git
If you don’t have a BitBucket account use https://bitbucket.org/dkistdc/solar-wavelength-calibration.git as the URL instead.
Linting
To replicate the standard developement workflow you must also install pre-commit and set it up to run whenever a git commit is made:
cd solar-wavelength-calibration
pre-commit install
To run pre-commit without having to make a commit simply run
pre-commit run --all-files
This will check the formatting of all code against the constraints defined in “.pre-commit-config.yaml”.
Unit Tests
Reference atlas test data
Install Git LFS and run git lfs install once for your user account before cloning. With the default LFS settings, git clone automatically downloads the complete atlas files.
Use the complete, solar and telluric atlases in solar_wavelength_calibration/tests/data/full-atlas/ for scientifically meaningful output. These canonical test data are stored with Git LFS.
Use the tiny test_*_reference_atlas.npy fixtures in solar_wavelength_calibration/tests/data/ when scientific output is immaterial, such as cache, download, configuration, and failure tests. Tiny fixtures remain in ordinary Git.
Running Tests
Unit tests can be run by installing an editable version and running pytest:
pip install -e .[test]
pytest -v --cov solar-wavelength-calibration
Changelog
When you make any change to this repository it MUST be accompanied by a changelog file. The changelog for this repository uses the towncrier package. Entries in the changelog for the next release are added as individual files (one per change) to the changelog/ directory.
Writing a Changelog Entry
A changelog entry accompanying a change should be added to the changelog/ directory. The name of a file in this directory follows a specific template:
<PULL REQUEST NUMBER>.<TYPE>[.<COUNTER>].rst
The fields have the following meanings:
<PULL REQUEST NUMBER>: This is the number of the pull request, so people can jump from the changelog entry to the diff on BitBucket.
<TYPE>: This is the type of the change and must be one of the values described below.
<COUNTER>: This is an optional field, if you make more than one change of the same type you can append a counter to the subsequent changes, i.e. 100.bugfix.rst and 100.bugfix.1.rst for two bugfix changes in the same PR.
The list of possible types is defined the the towncrier section of pyproject.toml, the types are:
feature: This change is a new code feature.
bugfix: This is a change which fixes a bug.
doc: A documentation change.
removal: A deprecation or removal of public API.
misc: Any small change which doesn’t fit anywhere else, such as a change to the package infrastructure.
Rendering the Changelog at Release Time
When you are about to tag a release first you must run towncrier to render the changelog. The steps for this are as follows:
Run towncrier build –version vx.y.z using the version number you want to tag.
Agree to have towncrier remove the fragments.
Add and commit your changes.
Tag the release.
NOTE: If you forget to add a Changelog entry to a tagged release (either manually or automatically with towncrier) then the Bitbucket pipeline will fail. To be able to use the same tag you must delete it locally and on the remote branch:
# First, actually update the CHANGELOG and commit the update
git commit
# Delete tags
git tag -d vWHATEVER.THE.VERSION
git push --delete origin vWHATEVER.THE.VERSION
# Re-tag with the same version
git tag vWHATEVER.THE.VERSION
git push --tags origin main
Deployment
solar-wavelength-calibration is deployed to PyPI as part of BitBucket pipelines that are run on commits to the “main” branch tagged with a version tag (vX.Y.Z).
Metadata
Release files for solar-wavelength-calibration 2.0.4
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| solar_wavelength_calibration-2.0.4.tar.gz | 198.1 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| solar_wavelength_calibration-2.0.4-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 252.3 kB
Release files / solar_wavelength_calibration-2.0.4.tar.gz
| Download URL | solar_wavelength_calibration-2.0.4.tar.gz |
|---|---|
| Size | 198.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
b9cfe503e2b0dd7a1440533b5ac5f091384d374ea9dd692b78ac17d1b0771f94
|
|
BLAKE2b-256 checksum How to use checksums |
2181c622d4f2268cc534ebf6f021468affc17b3bb958d632d39555f6608aba04
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.12.15
|
Release files / solar_wavelength_calibration-2.0.4-py3-none-any.whl
| Download URL | solar_wavelength_calibration-2.0.4-py3-none-any.whl |
|---|---|
| Size | 54.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
bd7e771bbfbc3b1e032195911d82fce690108311ad2266f88a7e84755a77c9b2
|
|
BLAKE2b-256 checksum How to use checksums |
ef64c8b5c9dfce16bb73234127e9af82acc8cf730dcc8710b7141966be5b8381
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.12.15
|