-
Notifications
You must be signed in to change notification settings - Fork 352
Description
Hey, folks! Hooray for making pytest a first party concern, and offering a pytest plugin 🎉!
Boo for the co-presence of jupyter_server
and pytest
making other people's entry_points
fail 👻!
Is there some way that pytest_tornasync
can be lazily loaded, etc. such that not everything needs to bring it in unless actually testing?
I mean, I love some entry_points
, and I would kill for jupyter_server
extensions to be able to be delivered via "normal means," if indeed entry_points
were the right way to do it (we some some knock-on effects here), but that software looks a bit long-in-the tooth (which is not necessarily a bad thing, but tornado has changed a fair amount), and I can never quite tell what plugins actually do to my pytest environment.
Alternatives
- basic approach for separate pytest plugin package #338: split that file into a separate package (though maybe not repo) altogether, e.g.
pytest_jupyter_server
- if you install it, because you're going to test (against)
jupyter_server
, it can bringpytest
,pytest_tornasync
, etc. along with a proper version pins
- if you install it, because you're going to test (against)
- Remove pytest11 entrypoint and plugin, require tornado 6.1, remove asyncio patch, CI work #339: keep the plugin here, but remove the
pytest11
entry_point
- if you're
pytest
ing, you're going to have aconftest.py
, and it is read last, andpytest_plugins = ["jupyter_server.pytest_plugin"]
isn't that big a lift
- if you're
The extras
don't really provide much assurance over time (basically ignored on subsequent solves), and pytest
(in)compatibility can be a really real thing, even at initialization time.
I also thought I read somewhere that the extras wouldn't even be part of some future state of the
pip
solver, but I can't back that up with a link.
related: