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 _______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
