You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have compatibility problems once in a while, making me think, since none of these features are astronomy specific, why this is code not part of pytest?
As there is already some doctest support in pytest it feels like it would not be out of scope if this were to be moved in. Why don't we ask the pytest devs if they would have it. If this needs a major refactor for 5.4 it sounds like the perfect opportunity to refactor it into core.
Then we must have this separately due to "historical reasons". A lot has changes since, so if they would take this into core, it would be great of course!
Full disclosre, I'm not a user of doctests in general (although I've contributed to pytest's doctest support in the past).
I see the following pytest-doctestplus features that are not available in pytest's core:
Float comparison
Ignoring warnings
Skip unconditionally
Dependencies
Remote Data (depends on pytest-remotedata)
All of them (except perhaps for "Remote Data" support) seem reasonable to have in the core.
As @bsipocz mentions, usually we prefer to extend pytest through plugins, but for features of the standard library where there's really not much diverting ways to go about it, integrating that feature into the core makes sense. To me doctesting falls into that category.
For an example of a feature that's in the standard library but we don't have plans to integrate into the core is async support: asyncio is in the standard library, but there are other libraries with asynchronous support , like trio and twisted, so it makes sense to have separate plugins for each: pytest-asyncio, pytest-trio, and pytest-twisted.
Integrating this to the core would require a champion however, someone who's willing to do the integration work and step up on occasion to help fix bugs on that module if they appear (of course core devs often help here, but is nice to have a champion/expert to turn to).
One advantage is that there would be no more compatibility problems, as they are now in the core so compatibility is guaranteed.
Having said all that, if a champion steps up, I would definitely be 👍 to integrate pytest-doctestplus into the core. I'm sure it would be very much appreciated by doctest users, as it introduces some very nice features.
personally i would prefer to merge the internal doctest plugin and this one into a pytest plugin thats outside of core but installed by default
Perhaps, as this brings logistics problems about how to test it properly with pytest to solve the compatibility problem brought up here, but either way the first step would be to merge it into the core, and then discuss it how to split it as a separate plugin. 👍
Activity
bsipocz commentedon Mar 17, 2020
I don't see this any different than the other plugins, and pytest's approach is to work with plugins. 🤷♀
pllim commentedon Mar 17, 2020
But the code here inherits a lot from
_pytest/doctest.py.Cadair commentedon Mar 18, 2020
As there is already some doctest support in pytest it feels like it would not be out of scope if this were to be moved in. Why don't we ask the pytest devs if they would have it. If this needs a major refactor for 5.4 it sounds like the perfect opportunity to refactor it into core.
bsipocz commentedon Mar 18, 2020
Then we must have this separately due to "historical reasons". A lot has changes since, so if they would take this into core, it would be great of course!
bsipocz commentedon Mar 18, 2020
What do you think @nicoddemus, ☝️
nicoddemus commentedon Mar 19, 2020
Hi everyone 👋,
Full disclosre, I'm not a user of doctests in general (although I've contributed to pytest's doctest support in the past).
I see the following
pytest-doctestplusfeatures that are not available in pytest's core:pytest-remotedata)All of them (except perhaps for "Remote Data" support) seem reasonable to have in the core.
As @bsipocz mentions, usually we prefer to extend pytest through plugins, but for features of the standard library where there's really not much diverting ways to go about it, integrating that feature into the core makes sense. To me doctesting falls into that category.
For an example of a feature that's in the standard library but we don't have plans to integrate into the core is
asyncsupport:asynciois in the standard library, but there are other libraries with asynchronous support , liketrioandtwisted, so it makes sense to have separate plugins for each:pytest-asyncio,pytest-trio, andpytest-twisted.Integrating this to the core would require a champion however, someone who's willing to do the integration work and step up on occasion to help fix bugs on that module if they appear (of course core devs often help here, but is nice to have a champion/expert to turn to).
One advantage is that there would be no more compatibility problems, as they are now in the core so compatibility is guaranteed.
Having said all that, if a champion steps up, I would definitely be 👍 to integrate
pytest-doctestplusinto the core. I'm sure it would be very much appreciated by doctest users, as it introduces some very nice features.@RonnyPfannschmidt @bluetech, opinions?
RonnyPfannschmidt commentedon Mar 19, 2020
personally i would prefer to merge the internal doctest plugin and this one into a pytest plugin thats outside of core but installed by default
personally i also dont use/avoid doctests
nicoddemus commentedon Mar 19, 2020
Perhaps, as this brings logistics problems about how to test it properly with pytest to solve the compatibility problem brought up here, but either way the first step would be to merge it into the core, and then discuss it how to split it as a separate plugin. 👍
pllim commentedon Mar 19, 2020
Re: champion -- pinging @astropy/coordinators
pllim commentedon Mar 19, 2020
Re: remote-data -- Yeah, maybe that can stay here or go to
pytest-remotedatasomehow.bsipocz commentedon Mar 19, 2020
Naively I don't think that can really go to remote data though as that's the bare minimum the doctests to know about the concept of remote-data
pllim commentedon Nov 30, 2020
Also see pytest-dev/pytest#8088
pllim commentedon May 30, 2023
Alas, this never happened, so now superseded by #199.