Issue 1:
We have accumulated a lot of dev automation tools, and our homegrown runtests.py CLI which is slightly clumsy. Here is an overview:

runtests.py - and its sibling dev.py for Meson

doc/Makefile - build docs and upload them

pavement.py - uses Paver for some release tasks

tox.ini - contains flake8 and pycodestyle config, we don't use Tox itself anymore

tools/authors.py / tools/gh_lists.py / tools/download-wheels.py release scripts

tasks for which we have no CLI, just docs that we hope people read before doing the thing they need:

dev environment setup - apt-get xxx && pip install yyy or conda env create -n environment.yml

git - for a lot of things, but with submodules it is getting less intuitive

docker - for Gitpod config, see tools/docker_dev

act - for running GitHub Actions jobs locally

Many of these things are badly maintained or only half in use. runtests.py has been the best maintained so far, but it's not ideal because task dependencies are manually dealt with in if args.some_task: ... logic.

Proposal: let's create a new and more ergonomic CLI for all development tools.

Ideally it has these properties:

Completeness: we have all normal/recurring development tasks implemented in it

Conciseness: (for example) do bench instead of python runtests.py --bench

Self-documenting: it should be easy to read the CLI implementation and figure out what actual commands are being run (or maybe the CLI can print the command)

Hierarchical: if there are a number of docs-related tasks, they should be discoverable and runnable like: do doc build, do doc show, do doc upload, etc. Same for CI and release tasks; top-level tasks should be for regular contributions/development

Genericity: it should make as few assumptions as possible (e.g., don't assume you're developing in a virtualenv), it should be implemented in a way where the non-SciPy-specific parts can be reused in other projects that use pytest/asv/meson/sphinx, and it should work in harmony with the tools it wraps so one can use those directly

There will be tools where it doesn't make sense to wrap them (e.g., gh) however it would be great if those tools could be made discoverable as well so it doesn't take new contributors years to find out about all of them.

I don't have a proposal (yet) for which framework or task runner to use. There are many. It looks like we need a straightforward task runner that understands dependencies between tasks and makes it easy to implement a CLI. Something like:

Airflow

Celery

doit

Invoke

Ones that I know of but aren't good choices: Paver (obsolete), Fabric (superceded by Invoke), Luigi (superceded by Airflow), Tox/Nox (they insist on environment activation/updates for every task).

Airflow is on the complicated (but powerful) side, doit is on the simple side. I don't have a lot of experience with any of these tools, so don't have a good sense for the features vs. simplicity tradeoff or other pros/cons. Suggestions very welcome.

Issue 2:
Is your feature request related to a problem? Please describe.

The RegularGridInterpolator tests often test multiple conditions inside the same test. This underreports the number and type of test failures. For example, test_nearest tests multiple different conditions, each of which should be its own test.

scipy/scipy/interpolate/tests/test_rgi.py

Lines 160 to 177
in
633172c

def test_nearest(self):

points, values = self._get_sample_4d()

interp = RegularGridInterpolator(points, values, method="nearest")

sample = np.asarray([0.1, 0.1, .9, .9])

wanted = 1100.

assert_array_almost_equal(interp(sample), wanted)

sample = np.asarray([0.1, 0.1, 0.1, 0.1])

wanted = 0.

assert_array_almost_equal(interp(sample), wanted)

sample = np.asarray([0., 0., 0., 0.])

wanted = 0.

assert_array_almost_equal(interp(sample), wanted)

sample = np.asarray([1., 1., 1., 1.])

wanted = 1111.

assert_array_almost_equal(interp(sample), wanted)

sample = np.asarray([0.1, 0.4, 0.6, 0.9])

wanted = 1055.

assert_array_almost_equal(interp(sample), wanted)

Describe the solution you'd like.

I'd like the tests to be parameterised so that each tested condition is its own test. This issue is for someone to go through the above tests and identify which tests can be parameterised and do it.

Describe alternatives you've considered.

We could leave it as is.

Additional context (e.g. screenshots, GIFs)

No response