[pytest-dev] Creating a complex PyTest program, wondering about the best way to handle collection errors, etc.

[Floris Bruynooghe]

On Fri 27 Apr 2018 at 15:15 -0500, Nicholas Williams wrote:

> One thing that concerned me in this whole process is that the vast majority
> of PyTest code appears to be behind a private API named `_pytest`. I was
> unable to implement this plugin without accessing these APIs. I could find
> no way around it. I minimized the imports as much as I could, even copying
> smaller sections of code instead of importing, but I still had to make
> these imports:
>
> from _pytest.unittest import (
>     TestCaseFunction,
>     UnitTestCase,
> )

I think the intention was the public API would be pytest.File,
pytest.Function, pytest.Collector, pytest.Instance and pytest.Item
(listed here in no particular order).  Your use case seems to want to
customise the existing unittest support which IIRC was never imagined
this would happen.  Hence you're either stuck re-creating lots of things
for the unittest support using the public APIs I've listed or importing
the private things I guess.  So maybe you have a valid case for wanting
pytest to expose a few more of the collecting semantics.  Would be best
to discuss and examine this in an issue/feature request I guess (if you
do so please mention me in the issue as otherwise I'll probably miss it)

> from _pytest._code.code import TracebackEntry
> from _pytest._code.source import Source
> from _pytest.mark import MARK_GEN

These are maybe somewhat more troubling, I'd have to look into these
carefully.  


> How much are we going to be able to rely on these staying fairly stable?
> I'd feel much better if these were public APIs. :-/

As I kind of suggest above, the second lot seems a lot scarier to me and
more likely to easily break.


Regards,
Floris