Hi everyone, i'd like to follow up on this one, as the work project switched from invoking pytest in process to invoking pytest as subprocess, the position/control of the rewriter is no longer a issue. Regards, Ronny On Sun, 2 Dec 2018 at 12:56, Floris Bruynooghe <flub@devork.be> wrote:

Hi Ronny,

On Thu 29 Nov 2018 at 15:57 +0100, Ronny Pfannschmidt wrote:

...

at a project at work which integrates pytest we did build a custom workflow around invoking tests and pytest.

This in turn triggers a lot of warnings from the assertion rewriter about things that have been already imported.

at first glance fixing this seems rather problematic, as the configuration of the assertion rewriting is deeply bound to the pytest configuration and it seems we cant do something simple and crude like letting a pth file fix the issue.

i believe opening up the hooking system could be best done by moving it to a package with some sort of singleton control anyway - then pytest would be just a consumer of that api enabling if not enabled and push in its own "import roots".

Having the assertion-rewriting in a separate package has been considered many times already and I can't remember anyone who was actually against this. I think it's just been waiting for someone to actually really need it and thus do it and have at least two consumers of the API.

So do you have any more ideas about what it would look like? As a random start I think some of these things should be in it:

- The AST-rewriter. Maybe a little more generalised than the pytest version, or at least allow for the API to grow in that direction. E.g customise the code with which the assert statement gets re-written.

- The import hook. I imagine this would not be installed at all as this would be up to the user of the package, e.g. pytest.

I'm not sure if this second part is what you had in mind, since it's still pytest which would install the import hook. But your problem description is a bit vague, so I'm not entirely sure what your aim is.

Cheers, Floris