one solution would be to set up a conftest.py that declares all necessary fixtures. and this also can be made to work in pants, but will require that all tests that use these kinds of fixtures declare conftest.py as a dependency

That makes the most sense to me. If you find it distasteful you could write a very small plugin that exposes a

conftests

target that comes with this dep automatically added and use that instead of

python_tests

in your BUILD file(s). This conversation was very confusing for me because it had little to do with pants and alot to do with pytest. Importing a fixture does not work - pants aside - if that fixture depends on another - even in the same file - unless you either a.) import it too (even though you don't use it) or b.) use conftest.py to register all your fixtures. I think the summary is that Pants can't help you today with the extras bogus imports technique in a.) and it forces you to make the implicit dependency on conftest.py to work its magic explicit for technique b.). I'm not sure how we'd make either better except to to ship a canned version of the

conftests

plugin target described above. If you can think of a better idea it's probably worth an enhancement/idea issue to flesh it out.

I see it as related to pants because the conftest.py solution is easy enough in a solution where you’re just using pytest, it’s using pants with pytest that starts to make things clunky. it also begins to subvert the general “only import what you need” philosophy of pants/build systems. which is why I asked here and not, say, a pytest forum, where the solution would be the very easy “just add it to your conftest.py” but yes, coming at it with just pants knowledge it’s definitely confusing

I'd personally take that as my cue to ditch pytest fixtures and use contextmanagers instead.

directly using context managers isn’t the best analogy, it’s a bit closer to setup/teardown that you get in other test frameworks. if I were starting from scratch I’m not sure I’d use pytest again with pants. but moving everything to unittest or something else is more than it makes sense to invest in right now

Yeah - if you already have a bunch of this in the codebase, a custom

contests

target is the minimal disruption way to go.