Update the documentation following the PyPI changes

doc/development/releasing.rst

@@ -5,6 +5,19 @@ Releasing a new version
 
 Most of the process related to releasing a new version of `cotainr` is automated. However a few things, as detailed on this page, must still be done to initiate the release process.
 
+Release process
+---------------
+In order to release a new version of `cotainr`, one must:
+
+1. Create a new branch with release notes in the format `YYYY.MM.MINOR.md` in the folder `doc/release_notes` based on the template `doc/release_notes/release_note.md.template`.
+2. Fill in the release notes.
+3. Assert succesful :ref:`CI tests <continuous_integration>` of the branch and merge the release notes into the main branch.
+4. Tag the main branch locally as `git tag YYYY.MM.MINOR`
+5. Push the tag to the GitHub repository `git push origin tag YYYY.MM.MINOR`. This launches the :ref:`CD on release <continuous_deployment>` GitHub action.
+6. Review the :ref:`CD on release <continuous_deployment>` GitHub action and approve the TestPyPI and PyPI deployment.
+
+.. _version-scheme:
+
 Versioning scheme
 -----------------
 A `CalVer <https://calver.org/>`_ versioning scheme is used for `cotainr`, more specifically:
@@ -18,15 +31,3 @@ with:
 - :code:`YYYY` - full year - 2022, 2023, ...
 - :code:`MM` - short month - 1, 2 ... 11, 12
 - :code:`MINOR` - zero-indexed counter specific to :code:`YYYY.MM` - 0, 1, ... - incremented for each version released in a given year/month.
-
-Release process
----------------
-In order to release a new version of `cotainr`, one must:
-
-1. Update the :attr:`cotainr.__version__` string in `cotianr/__init__.py`.
-2. Update the version switcher list by running the `doc/create_switcher.py` script.
-3. Create the associated release notes, i.e. create a `YYYY.MM.MINOR.md` file in the `doc/release_notes` folder based on the template `doc/release_notes/release_note.md.template`.
-4. Update the project README.md with new version in EasyBuild script (and possibly new `system.json` content).
-5. When all of these changes have been merged into *main* branch create a git tag (:code:`git tag YYYY.MM.MINOR`) for the version on the *main* branch and push it to the GitHub repository.
-6. Create a release on Github from the tag. Use the tag as release title and the release notes as description in MD-format.
-7. Assert that the :ref:`CD setup <continuous_delivery>` finishes correctly by checking that `readthedocs` is updated correctly (fx. that `stable <https://cotainr.readthedocs.io/en/stable>`_ and `latest <https://cotainr.readthedocs.io/en/latest>`_ points to the latest version and that the version is available by itself as well). If the version does not show up all builds from Read the Docs can be found under `versions <https://readthedocs.org/projects/cotainr/versions/>`_.

doc/development/test_suite_ci_cd.rst

@@ -8,16 +8,21 @@ Test suite & CI/CD
 The test suite
 --------------
 
-The `cotainr` test suite is implemented using `pytest <https://docs.pytest.org/>`_ and uses the `pytest-cov <https://docs.pytest.org/>`_ plugin for reporting test coverage. The entire test suite is run from the repository root directory by issuing:
+The `cotainr` test suite is implemented using `pytest <https://docs.pytest.org/>`_ and uses the `pytest-cov <https://docs.pytest.org/>`_ plugin for reporting test coverage. In order to run the test suite locally, first set up a developer environment and install the necessary dependencies using `uv sync`.
 
 .. code-block:: console
 
+    $ uv sync [--group tests]
+    $ uv run pytest
+
+Here the added specification `--group tests` is optional, because the default is `--group dev` which contains `tests`. The command `uv run pytest` executes the entire test suite and it is just a shorthand implementation of using a Python Virtual Environment,
+
+.. code-block:: console
+
+    $ uv venv
+    $ source .venv/bin/activate
     $ pytest
 
-Dependencies
-~~~~~~~~~~~~
-In order to run the tests, you must have the Python packages listed in the `test` extra.
-You can use ``pip install -e .[tests]`` to install the required packages.
 
 Pytest marks
 ~~~~~~~~~~~~
@@ -61,6 +66,8 @@ Imports in test modules are based on the following conventions:
 - Sub-package specific fixtures are explicitly imported using relative imports, e.g. :code:`from ..container.data import data_cached_ubuntu_sif` in `tests/pack/test_conda_install.py`.
 - Fixtures defined in `tests/conftest.py` are not explicitly imported (they are implicitly imported by `pytest``). Thus, if a fixture is used, but not imported, in a test module, `tests/conftest.py` is the only module in which it can (or at least should) be defined.
 
+.. _continuous_integration:
+
 Continuous Integration (CI)
 ---------------------------
 Continuous Integration (CI) is handled via `GitHub Actions <https://docs.github.com/en/actions>`_ in the `cotainr` GitHub repository https://github.com/DeiC-HPC/cotainr/actions. The tests run on the GitHub-hosted `ubuntu-latest <https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources>`_ runner. When running the CI test `matrix <https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs>`_, we differentiate between the following (meta)versions of dependencies:
@@ -82,12 +89,22 @@ The following CI `workflows <https://docs.github.com/en/actions/using-workflows/
   Lint and formatting checks (as described in the :ref:`style guide <style_guide>`) are also run and enforced.
 
 
-.. _continuous_delivery:
-
 Continuous Delivery (CD)
 ------------------------
 Continuous Delivery (CD) is handled partly via `GitHub Actions <https://docs.github.com/en/actions>`_, partly via the a `Read the Docs webhook integration <https://docs.readthedocs.io/en/stable/continuous-deployment.html>`_ to the `cotainr` GitHub repository: https://github.com/DeiC-HPC/cotainr/.
 
+.. _continuous_deployment:
+
+Continuous Deployment
+~~~~~~~~~~~~~~~~~~~~~
+New cotainr releases are automatically generated and deployed to both GitHub and PyPI when new tags following the :ref:`versioning scheme <version-scheme>` are committed to the main branch.
+The CD `workflow <https://docs.github.com/en/actions/using-workflows/about-workflows>`_ is implemented in `CD_release.yml <https://github.com/DeiC-HPC/cotainr/actions/workflows/CD_release.yml>`_.
+
+The PyPI release process goes as following: Build the Python Wheel -> Publish to TestPyPI index -> In a clean environment, download and install from TestPyPI and run basic CLI functionality -> publish to PyPI. The testPyPI and PyPI index locations are both implemented as GitHub environments attached to the DeiC-HPC account. These environments have deployment protection rules which require review from a member of the HPC-developers team before the action is executed. This ensures protection against accidental tag pushes since removal from TestPyPI and PyPI is difficult.
+
+The GitHub release is run independently and does not have deployment protection rules. GitHub releases can easily be undone by first removing the release through the GitHub UI and then remove the tag.
+
+
 Read the Docs continuous documentation
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 The :ref:`HTML documentation <building_the_html_docs>` served at http://cotainr.readthedocs.io is automatically built by Read the Docs based on the configuration in the `.readthedocs.yml configuration file <https://github.com/DeiC-HPC/cotainr/blob/main/.readthedocs.yml>`_.

doc/getting_started.rst

@@ -5,23 +5,16 @@ Getting Started
 
 `cotainr` makes it easy to build `Singularity`_/`Apptainer`_ containers for certain :ref:`use cases <use_cases>`. If this is your first time learning about `cotainr`, we encourage you to read the :ref:`motivation for using cotainr <why_cotainr>`.
 
-In order to get started using `cotainr`, you need to download and install the `cotainr` source code. Please note that cotainr only supports x86_64 and ARM64/AArch64 architectures. Alternative, you may be in luck that you are using an HPC system on which `cotainr` is already installed.
+In order to get started using `cotainr`, first be sure your system have the necessary :ref:`dependencies <cotainr_dependencies>` installed, then you can install `cotainr` directly using pip.
 
-.. grid:: 1
-    :gutter: 4
-
-    .. grid-item-card:: Getting the `cotainr` source code
-        :class-card: sd-rounded-0 sd-shadow-sm
+.. code-block:: console
 
-        All releases of `cotainr` are available on GitHub: https://github.com/DeiC-HPC/cotainr/releases
+    $ pip install cotainr
 
-        .. dropdown:: Installation instructions
-            :animate: fade-in
-            :color: secondary
+Alternatively, If you are using an HPC system, you may be in luck and find `cotainr` is already installed and refer to the following instructions.
 
-            `cotainr` only runs on Linux and requires that `Python`_ >=3.9 as well as `Singularity`_ >=3.7.4 [#]_ or `Apptainer`_ >=1.0.0 is installed on the system. More details about dependencies may be found in the :ref:`User Guide <cotainr_dependencies>`.
-
-            To install `cotainr`, download and unpack the source code. Then add the :code:`cotainr/bin` directory to your :code:`PATH` to get access to the :ref:`cotainr command line interface <command_line_interface>`.
+.. grid:: 1
+    :gutter: 4
 
     .. grid-item-card:: Using `cotainr` on HPC systems where it is already installed
 
@@ -50,6 +43,3 @@ In order to get started using `cotainr`, you need to download and install the `c
 .. _Apptainer: https://apptainer.org/
 .. _Python: https://www.python.org/
 .. _Singularity: https://sylabs.io/singularity/
-
-.. rubric:: Footnotes
-.. [#] As of version 3.8.0, Sylabs have changed the name of their version to SingularityCE. However, we only officially support their version from 3.9.2.