Clean way to optional enable/disable extensions

[asmeurer]

Now that we are adding more tests for the linalg extension, and we will soon have other extensions as well, we need to have a clean way for modules to not implement these extensions and not fail the test suite. Some test files mix extension and non-extension tests, e.g., the signature tests currently test all signatures.

This is closely related to #20.

[honno]

Bare minimum it would be nice if we automatically skipped tests if required attributes don't exist, like:

@pytest.mark.skipif(not hasattr(xp, "linalg")), reason="extension not found")

This could be a more immediate thing we do. Could be refactored to something like mark.requires_xp_linalg. We could create a custom option and use a hook in conftest.py down the line if we think its still useful to folks.

---

Side note: If we're interested in tracking the dependencies of the array module generally, EVERY test method could have something like mark.xp_deps([<attr names>]). We could can play around with pytest's collection to prioritise low dep things first, and automatically skip tests which are using faulty, more-"atomic" methods. e.g.:

@pytest.mark.xp_deps(["all", "equal"])
def test_foo(...):
    ...
    assert xp.all(...)
    assert xp.equal(...)

This would probably be too much of a headache, but something I'd consider in the future when this test suite is otherwise "complete". Good exercise for us to track dependencies too.

EDIT: I now realise this idea is particularly awkward as it'll need to declare dependencies on array object behaviour too. Also I see now with your recent comment that array_helpers.py already encourages limited deps.

[honno]

pytest.param() also allows us to specify marks, so linalg-related parameters in test_signatures.py could share the same marks we might use for all the linalg tests.

[asmeurer]

Is the set of active marks accessible from inside the test functions? It might be necessary to have branching logic in the test itself.

[honno]

Is the set of active marks accessible from inside the test functions? It might be necessary to have branching logic in the test itself.

Can't think of a way to do that myself. I suppose you could send marks as parameters and as the marks meta, i.e. param(..., marks, marks=marks).