Contributing to TeachBooks
==========================
We welcome any kind of contributions to our software, from simple
comment or question to a full fledged `pull request `_.
Please read and follow our :doc:`Code of Conduct `.
A contribution can be one of the following cases:
1. you have a question;
2. you think you may have found a bug (including unexpected behavior);
3. you want to make some kind of change to the code base (e.g. to fix a
bug, to add a new feature, to update documentation).
4. you want to make a release
The sections below outline the steps in each case.
You have a question
-------------------
1. use the search functionality
`here `__ to see
if someone already filed the same issue;
2. if your issue search did not yield any relevant results, make a new
issue;
3. apply the "Question" label; apply other labels when relevant.
You think you may have found a bug
----------------------------------
1. use the search functionality
`here `__ to see
if someone already filed the same issue;
2. if your issue search did not yield any relevant results, make a new
issue, making sure to provide enough information to the rest of the
community to understand the cause and context of the problem.
Depending on the issue, you may want to include:
- the `SHA hashcode `__
of the commit that is causing your problem;
- some identifying information (name and version number) for dependencies you're using;
- information about the operating system;
3. apply relevant labels to the newly created issue.
You want to make some kind of change to the code base
-----------------------------------------------------
#. (**important**) announce your plan to the rest of the community
*before you start working*. This announcement should be in the form
of a (new) issue;
#. (**important**) wait until some kind of consensus is reached about
your idea being a good idea;
#. if needed, fork the repository to your own Github profile and create
your own feature branch off of the latest main commit (typically the
``stable`` or ``develop`` branch). While working
on your feature branch, make sure to stay up to date with the main
branch by pulling in changes, possibly from the 'upstream'
repository (follow the instructions
`here `__
and `here `__);
#. install package main and dev dependencies. See the :ref:`dev-environment-setup`
below.
#. make sure the existing documentation can still by generated without
warnings by running ``cd docs && sphinx-build source/ _build/``.
#. add your own tests (if necessary), and make sure they run when you
run the test suite (using the command ``pytest``).
#. make sure your additions pass the static code analysis. You can run it
locally with the command ``ruff check``.
#. make sure your code is formatted correctly. You can run the formatter
locally with the command ``ruff format``.
#. update or expand the documentation; Please add `Google Style Python
docstrings `__.
#. `push `__ your feature
branch to (your fork of) the TeachBooks repository on GitHub;
#. create the pull request, e.g. following the instructions
`here `__.
In case you feel like you've made a valuable contribution, but you don't
know how to write or run tests for it, or how to generate the
documentation: don't let this discourage you from making the pull
request; we can help you! Just go ahead and submit the pull request, but
keep in mind that you might be asked to append additional commits to
your pull request.
.. _dev-environment-setup:
Set up a development environment
--------------------------------
As the package and its dependencies are installed using ``pip`` in the Deploy
Book Workflow (the GitHub Action for building books), it is best to do the
same with a development environment. Begin by cloning the repository and
creating a new branch from the appropriate branch and/or commit.
The creation of the development environment should be something like this:
.. code-block:: shell
conda deactivate # Only needed if you have conda
python3 -m venv venv # Create a virtual environment
source venv/bin/activate # or 'venv\Scripts\activate' on Windows
pip install -e .[dev]
pip show teachbooks # confirm local installation is used
Using option ``pip install -e`` is editable mode, which updates the
``teachbooks`` module in the ``venv`` as it is edited.
--------------------
**Windows Users**
The installation of the package using editable mode can take a
long time on Windows. This is recognizable via the command line interface
when the package installation process appears to be stuck while installing the
teachbooks package. The reason is most likely due to malware
scanners on organization-owned/managed computers. To resolve this there
are several options:
1. Disable (temporarily) the "Realtime malware protection" on your machine.
2. Stop and start the installation process several times.
3. Delete your environment and create it from scratch again.
In general, the `Setuptools manual
`__
can be a useful reference in case you run into issues here. Otherwise,
as you can probably already guess, the most effective solution for this
(and perhaps many of your other open source software problems) is to switch
to a Linux OS.
Use a development environment
-----------------------------
The instructions above will create a ``venv`` in the root directory of the
package repository, however, it may also be important to test unreleased
improvements to the source code by building a book in another repository.
To test the package on an book with source code in ``./book/`` stored
*outside* of the teachbooks repo will require using the relative path
to the venv (``PATH_TO_TEACHBOOKS_REPO``):
.. code-block:: shell
source PATH_TO_TEACHBOOKS_REPO/venv/bin/activate
pip install -r requirements.txt
teachbooks build book/
Alternatively, one could use one of the test books in ``./tests/``.
In fact, this is where tests should be added if making a new
contribution to the package.
You want to make a release
--------------------------
This section is for maintainers of the package.
#. Checkout ``HEAD`` of ``stable`` branch with ``git checkout stable`` and
``git pull``.
#. Determine what new version (major, minor or patch) to use. Package
uses `semantic versioning `__.
#. Because the stable branch is protected, you need to create a new branch
with ``git checkout -b release-``.
#. Set new version in ``pyproject.toml`` file in project section.
#. Update ``CHANGELOG.md`` with changes between current and new version.
#. Make sure all tests passed by running ``pytest``.
#. Commit & push changes to GitHub.
#. Create a pull request, review it, wait for actions to be green and
merge the pull request.
#. Wait for `GitHub
actions `__
on stable branch to be completed and green.
#. Create a `GitHub
release `__
- Use version as title and tag version.
- As description use intro text from ``README.md`` (to give context) and
changes from ``CHANGELOG.md``
#. Verify
1. Has `stable
ReadTheDocs `__
been updated?
2. Has the `Github publish
action `__
successfully uploaded the archives to
`PyPI `__?
3. Can new version be installed with pip using
``pip install teachbooks==``?
#. Celebrate
Releases and Versioning
-----------------------
Semantic numbering is used: ``vA.B.C``, where patches advance ``C`` and minor
releases advance ``B``. `Releases in the GitHub Repository
`__ deploy automatically
to `PyPI `__ once a tag is created and
the ``pyproject.toml`` file is updated with the new version number. Minor
releases will be merged into the ``stable`` branch (including those below
``v1.0.0``); patches may be incorporated in ``develop`` or ``stable``.
As described above, a Pull Request should be created when making a
contribution. A draft Pull Request may be set up between the ``develop`` and
``stable`` branches to preview updates for the next minor or major release.
If a release must be available on PyPI but it is not desired for it to be
available as the primary release, use the numbering ``vA.B.Cbn``, where ``n``
is an increasing number starting from 1. The specific version can be installed
via pip using ``pip install teachbooks==A.B.Cbn``. A tag defining this type of
release may be used on any branch.