Open DieTapete opened 1 day ago
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
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):
playwright
if you don't need it--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.
I started some experiments for typesetting alike/ I believe registring types that act as namespaces,+ declarations is the most viable way
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:
Alternatively there could be a function handling conflicts, a crude approach would look like this