Anyway to disable --noconftest?

[walrusVision]

Hi All

I'm trying to build in session fixtures into my conftest which provide a layer of safety to ensure that they cannot be run in the wrong environment. However I noticed that pytest come with an option --noconftest which appears to mean a developer could bypass any of those safe guards by not loading the conftest.

I'm trying to find if there is anyway to disable this flag for this project, but there doesn't appear to be an obvious way to do this.

Of course I can't put anything in the conftest itself, since its not loaded. The only option I've been able to work out, its to ensure that every module has an autouse session fixture which depends on the one in the conftest, which will cause them to all error out because they can't find the unloaded fixture name.

Is there a way to disable this, or best practices about this?

Thanks

[apoorva-01]

There's no flag to turn it off, but you don't really need one. Move the guard out of conftest.py and into a small plugin installed through the pytest11 entry point. --noconftest only skips conftest files, entry point plugins get loaded either way, so your session fixture survives it.

So a tiny local package with:

[project.entry-points.pytest11]
env_guard = "env_guard.plugin"

and in the plugin you can refuse the flag outright while you're at it:

import pytest

def pytest_configure(config):
    if config.option.noconftest:
        raise pytest.UsageError("--noconftest is not allowed in this project")

That's nicer than the autouse-fixture-in-every-module approach you worked out, mostly because nobody has to remember to add it to each new module.

Honest caveat: it isn't a lock. -p no:env_guard turns your plugin off, and --disable-plugin-autoload (or PYTEST_DISABLE_PLUGIN_AUTOLOAD=1) skips entry point loading entirely. Anyone who can type --noconftest can type those too. No pytest flag is going to hold as a security boundary when the person you're guarding against is the one writing the command line.

Which is fine if you're catching accidents, and that's usually the real thing you want. But if the worry is someone deliberately pointing the suite at the wrong environment, that guard has to live outside pytest. Best version is prod credentials just aren't reachable from a dev machine, so there's nothing to point at.