Conditional requirements support in wptrunner

[bashi]

Hi web-platform-tests,

I have a proposal to support conditional requirements in wptrunner. Context: https://github.com/web-platform-tests/wpt/pull/30570

[bashi]

@jgraham, @foolip What do you think?

@yutakahirano, @nidhijaju: FYI

[annevk]

It would help me if this had a more detailed explanation as to why this is a good thing. It says "there is a demand", but I don't see the demand being explained.

[bashi]

Thank you for feedback!

Does that mean the following example needs more explanations to clarify the benefits (not installing may-not-be-needed dependencies unconditionally)? Or are you suggesting that I should add alternatives considered (e.g. installing potential dependencies unconditionally) then discuss pros and cons (e.g. keeping wptrunner simple vs making wptrunner flexible for extension)?

[annevk]

I was thinking about the former, but both sounds great. In particular without such information my bias would be toward making it easy to run all tests in all browsers.

[bashi]

Thank you for the clarification. I updated the RFC and included these points.

+1 to making it easy to run all tests in all browsers. I'm happy to withdraw this proposal if adding aioquic dependency unconditionally makes sense :)

[jgraham]

There are a couple of things to consider here:

• We already support installing per-browser dependencies in wptrunner e.g. we don't insist on installing mozprofile to run tests except in Firefox, because having access to the correct versions of dependencies in CI is not always trivial (e.g. browser CI systems are typically not able to install stuff directly from PyPI for reliability reasons). We could solve this by vendoring everything, but we don't have good infrastructure to keep vendored deps up to date (and actually it's worse than that because in gecko CI we want to use the packages in mozilla-central, not vendored copies). So optional dependencies in general are considered OK.
• In the specific case of aioquic, I think the problem is the requirement for a compiled component somewhere in the chain. That means we can't simply vendor in the dep and expect things to work out; we either need other CI systems to be able to compile from source or to provide a binary wheel using whatever package source they have. Making the dep optional in the first place helps vendors to roll out support without risking widespread breakage.

[bashi]

Hi, any concerns on this proposal? If there is no substantive disagreement on this, I'd like to request merging this PR since 1 week has passed.