Why restricted to sdist?

[pytest-dev]

Why restricted to sdist?

[nicoddemus]

Hi @wimglenn,

Mostly because we rely on projects having a tox.ini file, which is only present in sdists.

About mentioning that somewhere on the README it makes sense, would you like to submit a PR? 😁

[wimglenn]

Oh OK - didn't realize this project was actually executing each plugin test suite, but it makes sense.

The OVERVIEW.md says:

If a plugin doesn't have a tox.ini file, we generate a simple tox.ini which just ensures that the plugin was installed successfully by running pytest --help.

But this is possible with bdist also, isn't it?

You might find more maintainers these days only using sdist if there needs to be extensions compiled..

[The-Compiler]

I'm not aware of any pytest plugins which need extensions - are there any?

[wimglenn]

I'm not aware either, and it's beside the point. The scripts look for projects doing CI with a tox.ini and making sdist avail, but it means that there can be some false negatives listed on the website.

[nicoddemus]

Oh yeah false negatives have always been a possibility, because some plugins might have complex dependencies (libraries, services, etc). pytest-qt is an example of that: besides needing PyQt5 or PySide, it also requires an xvfb server running, so plugincompat can't really test it.

[wimglenn]

@nicoddemus What do you think of giving a tick to a .whl with the correct filename tags ({distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl) which installs and displays in the pytest --help correctly? We can of course prefer sdist if available, and fall back to checking bdists...

[nicoddemus]

What do you think of giving a tick to a .whl with the correct filename tags ({distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl) which installs and displays in the pytest --help correctly?

Sounds like a good compromise. Would you like to open a PR? Should be simple enough to implement.

I've been thinking how useful those ticks are in reality TBH, because they give too much false negatives... it might be better to just list the plugins and their descriptions, and which Python version they declare to support. I don't know.

[wimglenn]

I began to work on it but there were some little things I was fixing up until it seemed there was so many of these that they should go in separate PR (see #26) so that it doesn't obscure the actual change too much.

But now it seems that travis-ci, as used to execute run.py and post results, is interfering with the PR builder. Could you untangle that so the PR builder is just executing the suite in test_web.py instead?