The following document describes the procedure to follow for making changes to KCWI_DRP.
There are three persistent branches in the KCWI_DRP repo:
master(default): This branch contains the current release version of the code, and provides the source used to build the package for
develop: This branch contains new features and non-essential fixes. It should be stable at all times. A new release is triggered by this branch being merged into
master. Any new code should be added to this branch.
documentation: This branch contains the documentation. Any new features or changes should be recorded here. For instructions on updating the docs, see the Updating Documentation page.
When adding new code, please do your development in a branch off of
git checkout develop git pull git checkout -b new_feature
While developing, it is important to stay up-to-date with any changes in the
git checkout develop git pull git checkout new_feature git merge --no-ff develop
Alternatively, you can do your own development in your own fork of the repo.
Once your new feature is ready for merging into the develop branch, you need to issue a pull request. The pull request must contain the following:
- A short but thorough explanation of the feature and its purpose
- A pass from the automatic TravisCI tests
- Evidence of successfully processing a night of KCWI data
Additionally, the code must meet the following:
- All code must be documented. This includes updated docstrings for altered code and new ones for new functions or classes
- Comments explaining any unusually complicated or unintuitive code blocks, in addition to the documentation above
- Remove all print statements. If you need to output information to terminal, use the logging interface
- At least two developers must approve of the request for it to be accepted
If your pull request meets all of the above, it will be merged into
during the next developer meeting.
At the developer’s discretion,
develop will be merged into
will signify a new sub-release. The version number should be incremented in
develop, and a summary of changes should be added to CHANGES.rst. Then,
issue and accept a pull request from
Building for Release¶
These instructions summarize the steps required to build a new release of
kcwidrp for conda or pip. These steps should be followed every time
After your pull request is merged into master, download the changes:
git checkout master git pull
Then, after ensuring the
dist directory is empty (ensure no previous
versions exist; these will conflict with the upload to PyPI):
# Make sure you have the most recent version of twine installed pip install twine --upgrade # Construct the pip distribution python setup.py sdist bdist_wheel # Test the upload by uploading to TestPyPI twine upload --repository-url https://test.pypi.org/legacy/ dist/* #If all went well with the test, upload to the permanent PyPI twine upload dist/*
Eventually, these steps will be rendered obsolete by the use of conda-forge. In the meantime, the following instructions will build a conda package from the pip package. This should be run whenever a new pip version is created.
conda update conda conda install conda-build anaconda-client conda-build conda_build_files conda build conda_build_files --output anaconda login anaconda upload PATH-FROM-OUTPUT