[TIP] Add pytest requires_dependency decorator in addition to importorskip?

Christoph Deil deil.christoph at googlemail.com
Thu Dec 8 00:19:23 PST 2016


Hi Bruno,

thanks for the quick and helpful reply!


> On 7 Dec 2016, at 22:23, Bruno Oliveira <nicoddemus at gmail.com> wrote:
> 
> Hi Christoph,
> 
> On Wed, Dec 7, 2016 at 11:51 AM Christoph Deil deil.christoph at googlemail.com <http://mailto:deil.christoph@googlemail.com/> wrote:
> 
> 
> 
> Are there any real pros and cons for the two options? Or are both equally powerful and it’s a matter of taste?
> 
> 
> IMHO it seems to be a matter of taste. The requires_dependency function still requires you to explicitly import the module inside the test file to obtain the module object:
> 
> from gammapy.utils.testing import requires_dependency
> 
> @requires_dependency('scipy')
> def test_using_scipy():
>     import scipy
> Compared with pytest.importorskip:
> 
> import pytest
> 
> def test_using_scipy():
>     scipy = pytest.importorskip('scipy')
> So I think requires_dependency has the following cons:
> 
> It might be more explicit, since pytest.importorskip might be used deep inside the test function and easy to miss, while the decorator stands out;
> It is more friendly to IDEs like PyCharm/PyDev, with code-completion, documentation, etc.
> The only cons I can think of is that it requires one extra line and the extra import (since it is common for tests to import pytest for other reasons as well).
> 
> 

Just to clarify: the way we handle optional dependencies in the (non-test) code is to put them as delayed imports only inside the function or method where they are used.

E.g. we have classes that have much functionality for computation, and then one plot method and only that requires “import matplotlib”, because that import is in the plot method.

So the extra “import scipy” line in the test code example you give above is never there in our tests.
> 
> 
> Do you think such a decorator would be appropriate for a pytest plugin?
> 
> 
> If others find it useful, I don’t see why not. :)
> 
> 
> 
> Or even to be proposed as a convenience for pytest core?
> 
> 
> I personally would be -0 on this because I feel it seems too similar to using pytest.importorskip method so I would avoid having two ways of doing the same thing. On the other hand, the implementation would be really simple so it wouldn’t be a maintenance burden if others really like it.
> 
> 

Makes sense.
> 
> 
> Or would you just recommend we implement what we want in our own `utils.py` instead of trying to generalise a solution for this?
> 
> 
> I think it is really commendable of you to try to provide a general solution to the community, so please don’t get discouraged by my -0. And since the implementation is simple and cookiecutter-pytest-plugin <https://github.com/pytest-dev/cookiecutter-pytest-plugin> makes creating plugins a snap, you should definitely go with it if you really prefer the decoration method.
> 
> 

I quickly looked through http://plugincompat.herokuapp.com/ <http://plugincompat.herokuapp.com/> and couldn’t find a plugin that does something like this, i.e. provide a decorator that can be used like this:
@requires_dependency(‘scipy”)
and maybe (to be discussed) a little more fancy strings and multiple checks like
@requires_dependency(‘scipy>=0.15, matplotlib’)

I’ll check out the pytest cookiecutter.

One basic question I still have is what the advantage is of having this as a Pytest plugin, instead of just a single-file .py module from which people can import the requires_dependency decorator? Would this allow me to expose the decorator in the top-level pytest or some other namespace? Is this a good idea?

Are there one or a few examples of plugins that I could look at before getting started that are similar to what I’m trying to do?

Cheers, Christoph

> Cheers,
> Bruno.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20161208/0a542ebc/attachment-0001.htm>


More information about the testing-in-python mailing list