Merge pull request pybamm-team#3005 from arjxn-py/Migrate-to-tox4

Migrate from `tox 3.28` to `nox`

.coveragerc

@@ -0,0 +1,3 @@
+[run]
+source = pybamm
+concurrency = multiprocessing

.github/workflows/run_benchmarks_over_history.yml

@@ -27,8 +27,8 @@ jobs:
         uses: actions/setup-python@v4
         with:
           python-version: 3.8
-      - name: Install tox and asv
-        run: pip install -U pip "tox<4" asv
+      - name: Install nox and asv
+        run: pip install -U pip nox asv
       - name: Fetch develop branch
         # Not required when worklow trigerred
         # on develop, but useful when

.github/workflows/run_periodic_tests.yml

@@ -86,46 +86,35 @@ jobs:
 
       - name: Install standard python dependencies
         run: |
-          python -m pip install --upgrade pip wheel setuptools
-          python -m pip install "tox<4"
-
+          python -m pip install --upgrade pip wheel setuptools nox
+  
       - name: Install SuiteSparse and Sundials
         if: matrix.os == 'ubuntu-latest'
-        run: tox -e pybamm-requires
+        run: nox -s pybamm-requires
 
       - name: Run unit tests for GNU/Linux with Python 3.8, 3.9, and 3.10
         if: matrix.os == 'ubuntu-latest' && matrix.python-version != 3.11
-        run: python -m tox -e unit
+        run: nox -s unit
 
       - name: Run unit tests for GNU/Linux with Python 3.11 and generate coverage report
         if: matrix.os == 'ubuntu-latest' && matrix.python-version == 3.11
-        run: python -m tox -e coverage
+        run: nox -s coverage
 
       - name: Upload coverage report
         if: matrix.os == 'ubuntu-latest' && matrix.python-version == 3.11
         uses: codecov/codecov-action@v2.1.0
 
-      - name: Run integration tests for GNU/Linux
-        if: matrix.os == 'ubuntu-latest'
-        run: python -m tox -e integration
+      - name: Run integration tests
+        run: nox -s integration
 
       - name: Run unit tests for Windows and MacOS
         if: matrix.os != 'ubuntu-latest'
-        run: python -m tox -e mac-windows-unit
-
-      - name: Run integration tests for Windows and MacOS
-        if: matrix.os != 'ubuntu-latest'
-        run: python -m tox -e mac-windows-integration
+        run: nox -s unit
 
       - name: Install docs dependencies and run doctests
         if: matrix.os == 'ubuntu-latest'
-        run: tox -e doctests
+        run: nox -s doctests
 
       - name: Install dev dependencies and run example tests
         if: matrix.os == 'ubuntu-latest'
-        run: tox -e examples
-
-      - name: Install scikits.odes and test pybamm_install_odes
-        if: matrix.os == 'ubuntu-latest'
-        run: |
-          tox -e odes
+        run: nox -s examples

.github/workflows/test_on_push.yml

@@ -96,36 +96,36 @@ jobs:
       - name: Install standard Python dependencies
         run: |
           python -m pip install --upgrade pip wheel setuptools
-          python -m pip install "tox<4"
+          python -m pip install nox
 
       - name: Install SuiteSparse and Sundials
         if: matrix.os == 'ubuntu-latest'
-        run: tox -e pybamm-requires
+        run: nox -s pybamm-requires
 
       - name: Run unit tests for GNU/Linux with Python 3.8, 3.9, and 3.10
         if: matrix.os == 'ubuntu-latest' && matrix.python-version != 3.11
-        run: python -m tox -e unit
+        run: nox -s unit
 
       - name: Run unit tests for GNU/Linux with Python 3.11 and generate coverage report
         if: matrix.os == 'ubuntu-latest' && matrix.python-version == 3.11
-        run: python -m tox -e coverage
+        run: nox -s coverage
 
       - name: Upload coverage report
         if: matrix.os == 'ubuntu-latest' && matrix.python-version == 3.11
         uses: codecov/codecov-action@v2.1.0
 
       - name: Run integration tests for GNU/Linux with Python 3.11
         if: matrix.os == 'ubuntu-latest' && matrix.python-version == 3.11
-        run: python -m tox -e integration
+        run: nox -s integration
 
       - name: Run unit tests for Windows and MacOS with all Python versions
         if: matrix.os != 'ubuntu-latest'
-        run: python -m tox -e mac-windows-unit
+        run: nox -s unit
 
       - name: Install docs dependencies and run doctests for GNU/Linux with Python 3.11
         if: matrix.os == 'ubuntu-latest' && matrix.python-version == 3.11
-        run: tox -e doctests
+        run: nox -s doctests
 
       - name: Install dev dependencies and run example tests for GNU/Linux with Python 3.11
         if: matrix.os == 'ubuntu-latest' && matrix.python-version == 3.11
-        run: tox -e examples
+        run: nox -s examples

.gitignore

@@ -113,6 +113,9 @@ test.json
 # tox
 .tox/
 
+# nox
+.nox/
+
 # vcpkg
 vcpkg_installed/
 

CHANGELOG.md

@@ -16,6 +16,7 @@
 
 - Test `JaxSolver`'s compatibility with Python `3.8`, `3.9`, `3.10`, and `3.11` ([#2958](https://github.com/pybamm-team/PyBaMM/pull/2958))
 - Update Jax (0.4.8) and JaxLib (0.4.7) compatibility ([#2927](https://github.com/pybamm-team/PyBaMM/pull/2927))
+- Migrate from `tox=3.28` to `nox` ([#3005](https://github.com/pybamm-team/PyBaMM/pull/3005))
 - Removed `importlib_metadata` as a required dependency for user installations ([#3050](https://github.com/pybamm-team/PyBaMM/pull/3050))
 
 ## Bug fixes
@@ -28,6 +29,7 @@
 ## Breaking changes
 
 - Deprecate functionality to load parameter set from a csv file. Parameter sets must now be provided as python dictionaries ([#2959](https://github.com/pybamm-team/PyBaMM/pull/2959))
+- Tox support for Installation & testing has now been replaced by Nox ([#3005](https://github.com/pybamm-team/PyBaMM/pull/3005))
 
 # [v23.4.1](https://github.com/pybamm-team/PyBaMM/tree/v23.4) - 2023-05-01
 

CONTRIBUTING.md

@@ -8,8 +8,8 @@ If you're already familiar with our workflow, maybe have a quick look at the [pr
 
 Before you commit any code, please perform the following checks:
 
-- [All tests pass](#testing): `$ tox -e unit` (GNU/Linux and MacOS), `$ python -m tox -e windows-unit` (Windows)
-- [The documentation builds](#building-the-documentation): `$ python -m tox -e docs`
+- [All tests pass](#testing): `$ nox -s unit`
+- [The documentation builds](#building-the-documentation): `$ nox -s docs`
 
 ### Installing and using pre-commit
 
@@ -44,7 +44,7 @@ You now have everything you need to start making changes!
 
 ### B. Writing your code
 
-6. PyBaMM is developed in [Python](<https://en.wikipedia.org/wiki/Python_(programming_language)>), and makes heavy use of [NumPy](https://en.wikipedia.org/wiki/NumPy) (see also [NumPy for MatLab users](https://numpy.org/doc/stable/user/numpy-for-matlab-users.html) and [Python for R users](http://blog.hackerearth.com/how-can-r-users-learn-python-for-data-science)).
+6. PyBaMM is developed in [Python](https://en.wikipedia.org/wiki/Python_(programming_language)), and makes heavy use of [NumPy](https://en.wikipedia.org/wiki/NumPy) (see also [NumPy for MatLab users](https://numpy.org/doc/stable/user/numpy-for-matlab-users.html) and [Python for R users](http://blog.hackerearth.com/how-can-r-users-learn-python-for-data-science)).
 7. Make sure to follow our [coding style guidelines](#coding-style-guidelines).
 8. Commit your changes to your branch with [useful, descriptive commit messages](https://chris.beams.io/posts/git-commit/): Remember these are publicly visible and should still make sense a few months ahead in time. While developing, you can keep using the GitHub issue you're working on as a place for discussion. [Refer to your commits](https://stackoverflow.com/questions/8910271/how-can-i-reference-a-commit-in-an-issue-comment-on-github) when discussing specific lines of code.
 9. If you want to add a dependency on another library, or re-use code you found somewhere else, have a look at [these guidelines](#dependencies-and-reusing-code).
@@ -136,12 +136,10 @@ This allows people to (1) use PyBaMM without ever importing Matplotlib and (2) c
 
 All code requires testing. We use the [unittest](https://docs.python.org/3.3/library/unittest.html) package for our tests. (These tests typically just check that the code runs without error, and so, are more _debugging_ than _testing_ in a strict sense. Nevertheless, they are very useful to have!)
 
-If you have tox installed, to run unit tests, type
+If you have nox installed, to run unit tests, type
 
 ```bash
-tox -e unit # (GNU/Linux and MacOS)
-#
-python -m tox -e windows-unit # (Windows)
+nox -s unit
 ```
 
 else, type
@@ -162,9 +160,7 @@ The tests are divided into `unit` tests, whose aim is to check individual bits o
 If you want to check integration tests as well as unit tests, type
 
 ```bash
-tox -e tests # (GNU/Linux and MacOS)
-#
-python -m tox -e windows-tests # (Windows)
+nox -s tests
 ```
 
 When you commit anything to PyBaMM, these checks will also be run automatically (see [infrastructure](#infrastructure)).
@@ -174,9 +170,7 @@ When you commit anything to PyBaMM, these checks will also be run automatically
 To test all example scripts and notebooks, type
 
 ```bash
-tox -e examples # (GNU/Linux and MacOS)
-#
-python -m tox -e windows-examples # (Windows)
+nox -s examples
 ```
 
 If notebooks fail because of changes to pybamm, it can be a bit of a hassle to debug. In these cases, you can create a temporary export of a notebook's Python content using
@@ -214,7 +208,6 @@ This also means that, if you can't fix the bug yourself, it will be much easier
    ```
 
    or by just commenting out all the tests you don't want to run.
-
 2. Set break points, either in your IDE or using the Python debugging module. To use the latter, add the following line where you want to set the break point
 
    ```python
@@ -240,7 +233,6 @@ This also means that, if you can't fix the bug yourself, it will be much easier
       ```
 
       This will start the debugger at the point where the `ValueError` was raised, and allow you to investigate further. Sometimes, it is more informative to put the try-except block further up the call stack than exactly where the error is raised.
-
    2. Warnings. If functions are raising warnings instead of errors, it can be hard to pinpoint where this is coming from. Here, you can use the `warnings` module to convert warnings to errors:
 
       ```python
@@ -249,23 +241,20 @@ This also means that, if you can't fix the bug yourself, it will be much easier
       ```
 
       Then you can use a try-except block, as in a., but with, for example, `RuntimeWarning` instead of `ValueError`.
-
    3. Stepping through the expression tree. Most calls in PyBaMM are operations on [expression trees](https://github.com/pybamm-team/PyBaMM/blob/develop/examples/notebooks/expression_tree/expression-tree.ipynb). To view an expression tree in ipython, you can use the `render` command:
 
       ```python
       expression_tree.render()
       ```
 
       You can then step through the expression tree, using the `children` attribute, to pinpoint exactly where a bug is coming from. For example, if `expression_tree.jac(y)` is failing, you can check `expression_tree.children[0].jac(y)`, then `expression_tree.children[0].children[0].jac(y)`, etc.
-
 3. To isolate whether a bug is in a model, its Jacobian or its simplified version, you can set the `use_jacobian` and/or `use_simplify` attributes of the model to `False` (they are both `True` by default for most models).
 4. If a model isn't giving the answer you expect, you can try comparing it to other models. For example, you can investigate parameter limits in which two models should give the same answer by setting some parameters to be small or zero. The `StandardOutputComparison` class can be used to compare some standard outputs from battery models.
 5. To get more information about what is going on under the hood, and hence understand what is causing the bug, you can set the [logging](https://realpython.com/python-logging/) level to `DEBUG` by adding the following line to your test or script:
 
    ```python3
    pybamm.set_logging_level("DEBUG")
    ```
-
 6. In models that inherit from `pybamm.BaseBatteryModel` (i.e. any battery model), you can use `self.process_parameters_and_discretise` to process a symbol and see what it will look like.
 
 ### Profiling
@@ -285,7 +274,6 @@ as above, and then use some of the profiling tools. In order of increasing detai
    ```
 
    tells you how long the line `command_to_time()` takes. You can use `%timeit` instead to run the command several times and obtain more accurate timings.
-
 2. Simple profiler. Using `%prun` instead of `%time` will give a brief profiling report 3. Detailed profiler. You can install the detailed profiler `snakeviz` through pip:
 
    ```bash
@@ -307,7 +295,7 @@ PyBaMM is documented in several ways.
 
 First and foremost, every method and every class should have a [docstring](https://www.python.org/dev/peps/pep-0257/) that describes in plain terms what it does, and what the expected input and output is.
 
-These docstrings can be fairly simple, but can also make use of [reStructuredText](http://docutils.sourceforge.net/docs/user/rst/quickref.html), a markup language designed specifically for writing [technical documentation](https://en.wikipedia.org/wiki/ReStructuredText). For example, you can link to other classes and methods by writing `` :class:`pybamm.Model`  `` and `` :meth:`run()`  ``.
+These docstrings can be fairly simple, but can also make use of [reStructuredText](http://docutils.sourceforge.net/docs/user/rst/quickref.html), a markup language designed specifically for writing [technical documentation](https://en.wikipedia.org/wiki/ReStructuredText). For example, you can link to other classes and methods by writing ``:class:`pybamm.Model` `` and ``:meth:`run()` ``.
 
 In addition, we write a (very) small bit of documentation in separate reStructuredText files in the `docs` directory. Most of what these files do is simply import docstrings from the source code. But they also do things like add tables and indexes. If you've added a new class to a module, search the `docs` directory for that module's `.rst` file and add your class (in alphabetical order) to its index. If you've added a whole new module, copy-paste another module's file and add a link to your new file in the appropriate `index.rst` file.
 
@@ -318,7 +306,7 @@ Using [Sphinx](http://www.sphinx-doc.org/en/stable/) the documentation in `docs`
 To test and debug the documentation, it's best to build it locally. To do this, navigate to your PyBaMM directory in a console, and then type:
 
 ```
-python -m tox -e docs (GNU/Linux, MacOS and Windows)
+nox -s docs (GNU/Linux, MacOS and Windows)
 ```
 
 And then visit the webpage served at http://127.0.0.1:8000. Each time a change to the documentation source is detected, the HTML is rebuilt and the browser automatically reloaded.
@@ -384,7 +372,7 @@ Code coverage (how much of our code is actually seen by the (linux) unit tests)
 Configuration files:
 
 ```
-tox.ini
+.coveragerc
 ```
 
 ### Read the Docs