Provide for including fixtures from common location [improvement]

[astraw38]

It'd be very convenient to have a method similar to pytest_plugins = ['path.to.plugin'], but purely for fixture inclusion.

Reasoning:

• You can move common fixtures to a parent conftest.py, but that can lead to exceptionally large conftest.py files in larger projects
• Would let you keep similar fixtures grouped together for common imports/functionality
• You can import fixtures from other locations, but if you don't directly reference them, they are seen as 'unused' by most linters.

[pytestbot]

GitMate.io thinks possibly related issues are #1050 (provide dependency-tested autouse fixtures), #3351 (Is there a way to provide mark with fixture params), #1376 (allow fixtures to provide extra info when a test fails), #2502 (How to provide fixture parameters at test level?), and #1216 (Provide a way to nicely control fixture execution order ).

[nicoddemus]

Thanks @astraw38,

You can move common fixtures to a parent conftest.py, but that can lead to exceptionally large conftest.py files in larger projects

Here's a solution to this problem: #3582 (comment)

IMHO this is enough to which I think fits your requirements 1 and 2. What do you think?

[astraw38]

Importing isn't ideal, because you get unused imports warnings from most code analysis tools, and invariably you'll have to deal with someone 'optimizing' those imports later, and breaking your conftest.

[nicoddemus]

I see. Usually putting a few # noqa solves the problem, but I see your point.

Btw, you don't want to use pytest_plugins because you don't want to make the fixtures globally available?

I ask because pytest_plugins will also work for fixtures:

pytest_plugin = ['myapp.some_fixtures', 'myapp.other_fixtures']

[astraw38]

Exactly. It's rather unintuitive that it would affect global scope. For most fixtures, not that big of a deal, but could be a problem with autouse fixtures (and would pollute the output of pytest --fixtures).

[nicoddemus]

OK, thanks for the clarification.

[ikonst]

@astraw38 see the approach I've eventually adopted:
#3582 (comment)