Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Offer a way to handle conflicting options #12915

Open
DieTapete opened this issue Oct 25, 2024 · 4 comments
Open

Offer a way to handle conflicting options #12915

DieTapete opened this issue Oct 25, 2024 · 4 comments
Labels
topic: config related to config handling, argument parsing and config file type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature

Comments

@DieTapete
Copy link

What's the problem this feature will solve?

When a user installs multiple plugins it is often the case that there are conflicting options. Currently there is no way to handle those conflicts but to uninstall one of the conflicting plugins. Also when adding custom options the user is forced to rename the option.

Describe the solution you'd like

There should be a way to either define a resolution for a conflict or to remove one of the conflicting options.

For example in the following case I remove a conflicting option from the playwright plugin before I add my own:

def pytest_addoption(parser):
    pw_options = parser.getgroup("playwright", "Playwright")
    # either rename the options
    pw_options.renameoption('--device', '--machine')
    # or remove it
    pw_options.removeoption('--device')
    parser.addoption(
        "--device",
        action="store",
        choices=devices
    )

Alternatively there could be a function handling conflicts, a crude approach would look like this

def resolve_options(option1, option2):
    if option1.group is None:
        return option1
    return option2

def pytest_addoption(parser):
    parser.conflict_handler = resolve_options
@RonnyPfannschmidt
Copy link
Member

The namespace where the values land are currently the same

Additionally options having different names based on the set of installed plugins would be a ux disaster

A mechanism for namespaced long names plus conflict averse lookup is necessary

@The-Compiler
Copy link
Member

I don't think "it is often the case" is really accurate here, given how rarely this comes up.

In any case, I don't think pytest can easily solve this. The public-facing option values is not the only thing that conflicts, but as @RonnyPfannschmidt hints at, receiving options is also a shared namespace. If you remove/rename the option from Playwright, what's going to happen when Playwright reads pytestconfig.option.device? And how could that possibly differ from what happens if you yourself read pytestconfig.option.device instead?

Without fundamental changes on how plugins register and receive options, this can only be fixed in cooperation with the affected plugin(s):

  • Don't install/load the playwright if you don't need it
  • Pick an alternative name that doesn't conflict
  • Ask playwright to pick an alternative name (say, --playwright-device), which of course won't be backwards compatible.

I agree something like you propose would be very confusing, but for it to be possible in the first place, pytest would need something like a parser.add_plugin_option("playwright", "--device") and pytestconfig.plugin_option.playwright.device. Only then it could (perhaps optionally / on request) expose that as --playwright-device instead of just --device - but this only works if there is a per-plugin namespace to read it.

@RonnyPfannschmidt
Copy link
Member

I started some experiments for typesetting alike/ I believe registring types that act as namespaces,+ declarations is the most viable way

@DieTapete
Copy link
Author

Thank you for your input. In my case I kind of just want to disable the playwright option as we are not planning on using it and instead need to use that argument ourselves. So I guess disabling it would be okay but I understand the complications when considering a more generalized solution.

@Zac-HD Zac-HD added type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature topic: config related to config handling, argument parsing and config file labels Oct 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: config related to config handling, argument parsing and config file type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Projects
None yet
Development

No branches or pull requests

4 participants