Fix: review fixes from Trevor

Co-authored-by: Trevor James Smith <[email protected]>

Fix: edit from trevor

Co-authored-by: Trevor James Smith <[email protected]>

Fix: edit from trevor

Co-authored-by: Trevor James Smith <[email protected]>

Fix: edits from Trevor

Co-authored-by: Trevor James Smith <[email protected]>

Fix: edits from Nick

Co-authored-by: Nick Murphy <[email protected]>

Packaging image

Fix: remove unused block

Fix

Update ci-tests-data/tests-ci.md

Co-authored-by: Trevor James Smith <[email protected]>

Author: lwasser

ci-tests-data/ci.md

@@ -47,7 +47,7 @@ If you are using GitLab CI/CD many of the principles described here will apply,
 ### If you aren't sure, use GitHub Actions
 
 While you are welcome to use the continuous integration platform of your choice,
-we recommend Github actions because it is free-to-use and integrated tightly
+we recommend GitHub Actions because it is free-to-use and integrated tightly
 into the GitHub user interface. There is also an entire store of GitHub action
 templates that you can easily use and adapt to your own needs.
 

ci-tests-data/code-cov.md

@@ -2,12 +2,12 @@
 
 Code coverage is the amount of your package's codebase that is run as a part of running your project's tests. A good rule of thumb is to ensure that every line of your code is run at least once during testing. However, note that good code coverage does not guarantee that your package is well-tested. For example, you may run all of your lines of code, but not account for many edge-cases that users may have. Ultimately, you should think carefully about the way your package will be used, and decide whether your tests adequately cover all of that usage.
 
-A common service for analyzing code coverage is [codecov.io](https://codecov.io/). This project is free for open source tools, and will provide dashboards that tell you how much of your codebase is covered during your tests. We recommend setting up an account, and using codecov to keep track of your code coverage.
+Some common services for analyzing code coverage are [codecov.io](https://codecov.io/) and [coveralls.io](https://coveralls.io/). These projects are free for open source tools, and will provide dashboards that tell you how much of your codebase is covered during your tests. We recommend setting up an account (on either CodeCov or Coveralls), and using it to keep track of your code coverage.
 
 ```{figure} ../images/code-cov-stravalib.png
 :height: 450px
 :alt: Screenshot of the code cov service - showing test coverage for the stravalib package. in this image you can see a list of package modules and the associated number of lines and % lines covered by tests. at the top of the image you can see what branch is being evaluated and the path to the repository being shown.
 
-the Code cov platform is a useful tool if you wish to visually track code coverage. Using it you can not only get the same summary information that you can get with **pytest-cov** extension. You can also get a visual representation of what lines are covered by your tests and what lines are not covered. Code cove is mostly useful for evaluating unit tests and/or how much of your package code is "covered. It however will not evaluate things like integration tests and end-to-end workflows.
+The CodeCov platform is a useful tool if you wish to visually track code coverage. Using it you can not only get the same summary information that you can get with **pytest-cov** extension. You can also get a visual representation of what lines are covered by your tests and what lines are not covered. Code coverage is mostly useful for evaluating unit tests and/or how much of your package code is "covered". It however will not evaluate things like integration tests and end-to-end workflows.
 
 ```

ci-tests-data/index.md

@@ -1,7 +1,17 @@
 # Tests and data for your Python package
 
 In this section you will learn more about the importance of writing
-tests for you Python package.
+tests for your Python package.
+
+
+:::{figure-md} fig-target
+
+<img src="../images/packaging-lifecycle.png" alt="" width="800px">
+
+Fix-- highlight the tests part of the circle and make everything else grey / not colored??
+:::
+
+
 
 ::::{grid} 1 1 2 2
 :class-container: text-center

ci-tests-data/run-tests.md

@@ -48,7 +48,7 @@ calling:
 
 `pytest`
 
-Or if you want to run a specific test file - let's call such file - filename.py - you can run:
+Or if you want to run a specific test file - let's call this file "filename.py" - you can run:
 
 `pytest filename.py`
 
@@ -67,17 +67,17 @@ in various Python environments.
 
 ### Tools to automate running your tests
 
-To run tests on various Python versions or in various specific environments with a single command, you can use an automation tool such as nox or tox.
-Both nox and tox can create an isolated virtual environment that you define. This allows you to easily run your tests in multiple environments and across Python versions.
+To run tests on various Python versions or in various specific environments with a single command, you can use an automation tool such as `nox` or `tox`.
+Both `nox` and `tox` can create an isolated virtual environment that you define. This allows you to easily run your tests in multiple environments and across Python versions.
 
-We will focus on [Nox](https://nox.thea.codes/) in this guide. nox is a Python-based automation tool that builds upon the features of both Make and Tox. Nox is designed to simplify and streamline testing and development workflows. Everything that you do with nox can be implemented using a Python-based interface.
+We will focus on [Nox](https://nox.thea.codes/) in this guide. `nox` is a Python-based automation tool that builds upon the features of both `make` and `tox`. `nox` is designed to simplify and streamline testing and development workflows. Everything that you do with `nox` can be implemented using a Python-based interface.
 
 ```{admonition} Other automation tools you'll see in the wild
 :class: note
 
 - **[Tox](https://tox.wiki/en/latest/index.html#useful-links)** is an automation tool that supports common steps such as building documentation, running tests across various versions of Python, and more. You can find [a nice overview of tox in the plasmaPy documentation](https://docs.plasmapy.org/en/stable/contributing/testing_guide.html#using-tox).
 
-- **[Hatch](https://github.com/ofek/hatch)** is a modern end-to-end packaging tool that works with the popular build backend called hatchling. Hatch offers a tox-like setup where you can run tests locally using different Python versions. If you are using hatch to support your packaging workflow, you may want to also use its testing capabilities rather than using nox.
+- **[Hatch](https://github.com/ofek/hatch)** is a modern end-to-end packaging tool that works with the popular build backend called hatchling. `hatch` offers a `tox`-like setup where you can run tests locally using different Python versions. If you are using `hatch` to support your packaging workflow, you may want to also use its testing capabilities rather than using `nox`.
 
 * [**make:**](https://www.gnu.org/software/make/manual/make.html) Some developers use Make, which is a build automation tool, for running tests
 due to its versatility; it's not tied to a specific language and can be used
@@ -93,17 +93,17 @@ with it. Make also won't manage environments for you like **nox** will do.
 - Python-based making it accessible if you already know Python and
 - It will create isolated environments to run workflows.
 
-Nox simplifies creating and managing testing environments. With Nox, you can
+`nox` simplifies creating and managing testing environments. With `nox`, you can
 set up virtual environments, and run tests across Python versions using the environment manager of your choice with a
 single command.
 
 Nox can also be used for other development tasks such as building
 documentation, creating your package distribution, and testing across various
-environment managers such as conda and pip.
+environment managers such as `conda` and `pip`.
 
 ## Test Environments
 
-By default, Nox uses the Python built in `venv` environment manager. A virtual environment (`venv`) is a self-contained Python environment that allows you to isolate and manage dependencies for different Python projects. It helps ensure that project-specific libraries and packages do not interfere with each other, promoting a clean and organized development environment.
+By default, `nox` uses the Python built in `venv` environment manager. A virtual environment (`venv`) is a self-contained Python environment that allows you to isolate and manage dependencies for different Python projects. It helps ensure that project-specific libraries and packages do not interfere with each other, promoting a clean and organized development environment.
 
 An example of using nox to run tests in `venv` environments for Python versions 3.9, 3.10 and 3.11 is below.
 
@@ -119,8 +119,8 @@ TODO: add some tests above and show what the output would look like in the examp
 
 Below is an example of setting up nox to run tests using `venv` which is the built in environment manager that comes with base Python.
 
-Note that the example below assumes that you have setup your pyproject.toml to declare test dependencies in a way that pip
-can understand. And example of that setup is below.
+Note that the example below assumes that you have [setup your `pyproject.toml` to declare test dependencies in a way that pip
+can understand](../package-structure-code/declare-dependencies.md). And example of that setup is below.
 
 ```toml
 [project]
@@ -173,7 +173,7 @@ Note that unlike venv, conda can automatically install
 the various versions of Python that you need. You won't need to install all three Python versions if you use conda/mamba, like you do with `venv`.
 
 ```{note}
-For conda to work with nox, you will need to
+For `conda` to work with `nox`, you will need to
 install a conda-friendly version of Python. We suggest
 the mamba-forge installation.
 
@@ -202,19 +202,3 @@ To run the above session you'd use:
 ```bash
 nox -s test_mamba
 ```
-
-## IGNORE ME - testing doctest (not working now)
-
-```{testcode}
-a = 1+2
-print(a)
-```
-
-```{testoutput}
-
-```
-
-TODO: might be able to use doctest to run examples However so far it's not working as intended and may be extra work.
-https://www.sphinx-doc.org/en/master/usage/extensions/doctest.html
-
----

ci-tests-data/tests-ci.md

@@ -49,14 +49,15 @@ jobs:
         python-version: ["3.9", "3.10", "3.11"]
 
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
         with:
           # fetch more than the last single commit to help scm generate proper version
           fetch-depth: 20
       - name: Set up Python ${{ matrix.python-version }}
         uses: actions/setup-python@v4
         with:
           python-version: ${{ matrix.python-version }}
+          cache: pip # By adding cache here, you are telling actions to reuse installed dependencies rather than re-downloading and installing them each time. This speeds up your workflow
 
       # This step and the step below are an optional steps to cache variables to make your build faster / more efficient
       - name: Set Variables
@@ -73,7 +74,7 @@ jobs:
       - name: Install dependencies
         run: |
           python -m pip install --upgrade pip
-          pip install nox
+          python -m pip install nox
       - name: List installed packages
         run: pip list
       - name: Run tests with pytest & nox