pytest-dev / plugincompat Goto Github PK

page is currently empty - some trouble with mongodb?

As commented, change column ordering

Here is some info to update:

1. The same plugin is listed twice:

• pytest-nbsmoke
• nbsmoke

The second entry should remain, the first one deleted. (plugin was renamed)

2. pytest-ipynb is no longer maintained. so https://pypi.org/project/pytest-ipynb is 404. Yet, it's still a well functioning and useful plugin, so perhaps linking to its archived github project is better than removing it completely - perhaps someone will take over its maintenance. Link: https://github.com/zonca/pytest-ipynb

Thanks.

Freeze requirements to ensure the production slug matches the development environment.

https://www.kennethreitz.org/essays/a-better-pip-workflow

for pytest-incremental 0.4.2 on py27 The result is "?" and the output is: <no output available>

Any idea how can I fix that? is it my plugin problem?

It seems that as of May 23, the technique no longer works but instead returns empty results. 4e325f7

bellow you can find error with simple debug print, where is displayed name of plugin and list or releases.
you can see that pytest-voluptuous did hide releases, and it made this script to fail on InxexError.

$ python update_index.py 
pytest-falcon ['0.4.2']
pytest-regtest ['0.15.0']
pytest-param ['0.1.1']
pytest-voluptuous []
Traceback (most recent call last):
  File "update_index.py", line 109, in <module>
    main()
  File "update_index.py", line 100, in main
    plugins = sorted(iter_plugins(client))
  File "update_index.py", line 48, in iter_plugins
    names_and_versions[name] = sorted(versions, key=LooseVersion)[0]
IndexError: list index out of range

As per pypi/warehouse#8753, we must now rate limit how we send requests to PyPI

If we don't we receive xmlrpc.client.Fault errors:

$ python3 update_index.py
Traceback (most recent call last):
  File "update_index.py", line 109, in <module>
    main()
  File "update_index.py", line 100, in main
    plugins = sorted(iter_plugins(client, BLACKLIST, consider_classifier=False))
  File "update_index.py", line 41, in iter_plugins
    versions = client.package_releases(name)
  File "/usr/lib/python3.6/xmlrpc/client.py", line 1112, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python3.6/xmlrpc/client.py", line 1452, in __request
    verbose=self.__verbose
  File "/usr/lib/python3.6/xmlrpc/client.py", line 1154, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib/python3.6/xmlrpc/client.py", line 1170, in single_request
    return self.parse_response(resp)
  File "/usr/lib/python3.6/xmlrpc/client.py", line 1342, in parse_response
    return u.close()
  File "/usr/lib/python3.6/xmlrpc/client.py", line 656, in close
    raise Fault(**self._stack[0])
xmlrpc.client.Fault: <Fault -32500: 'HTTPTooManyRequests: The action could not be performed because there were too many requests by the client. Limit may reset in 1 seconds.'>
$

I am working on fixing this. I should have a PR up today or tomorrow, if that is OK with you @nicoddemus

This website was an excellent learning tool, and provides a nice list of all pytest plugins available.

It however implements a non-trivial workflow and maintaining the website has a non-zero cost in time.

The compatibility testing done here is not really useful in the end (#39), it seems the most useful thing about the website is the list of plugins, which we now have in the pytest documentation itself:

https://docs.pytest.org/en/latest/reference/plugin_list.html

Other than that, there is a number of issues/improvements/fixes that are interesting but I don't really have the time to tackle:

• False positives when using the Framework :: Pytest classifier: #53.

• JSON API support (#61)

• Other enhancements/fixes: #54, #38, #11, #7

I don't really see the point in evolving the website any further given that the official plugin list now exists and provides a good overview of the plugin ecosystem.

Thanks for all the contributors, every help was highly appreciated!

PyPI has introduced a new JSON api. As a result, the xml-rpc api is being phased out.

SInce PyPI introduced rate limiting for the xml-rpc api ( see #59 and #60 ) it would make sense for us to migrate now since (a) the library is deprecated and (b) moving to JSON should provide performance gains

pytest-dev/pytest-cov#254 (comment)

It seems a lot of packages are using the Framework :: Pytest classifier even though they are not plugins, but only use pytest to test their own code. This generates a bunch of false positives that we should avoid showing.

Hi, given the recent discussion at FOSDEM what about moving this repo to pytest-dev/plugincompat ? (it should not be prefixed "pytest-" because that signals a plugin.

I'm the developer for the pytest-mpl plugin:

https://github.com/astrofrog/pytest-mpl

This plugin first appeared on plugincompat for version 0.2, which didn't have a tox.ini file. I've since added one in version 0.3, but it looks like the new file is not getting used because matplotlib doesn't get installed:

http://plugincompat.herokuapp.com/output/pytest-mpl-0.3?py=py34&pytest=2.6.4

Does the .tox folder need to be wiped clean for the change to take effect?

Few plugins fail now with peculiar errors like:

Traceback (most recent call last):
  File "/home/travis/virtualenv/python2.7.9/bin/tox", line 9, in <module>
    load_entry_point('tox==1.8.2.dev1', 'console_scripts', 'tox')()
  File "/home/travis/virtualenv/python2.7.9/src/tox/tox/_cmdline.py", line 25, in main
    config = parseconfig(args, 'tox')
  File "/home/travis/virtualenv/python2.7.9/src/tox/tox/_config.py", line 42, in parseconfig
    parseini(config, inipath)
  File "/home/travis/virtualenv/python2.7.9/src/tox/tox/_config.py", line 299, in __init__
    self._makeenvconfig(name, section, reader._subs, config)
  File "/home/travis/virtualenv/python2.7.9/src/tox/tox/_config.py", line 374, in _makeenvconfig
    name = self._replace_forced_dep(name, config)
  File "/home/travis/virtualenv/python2.7.9/src/tox/tox/_config.py", line 432, in _replace_forced_dep
    if self._is_same_dep(forced_dep, name):
  File "/home/travis/virtualenv/python2.7.9/src/tox/tox/_config.py", line 443, in _is_same_dep
    dep2_name = pkg_resources.Requirement.parse(dep2).project_name
  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/pkg_resources.py", line 2745, in parse
    reqs = list(parse_requirements(s))
  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/pkg_resources.py", line 2678, in parse_requirements
    "version spec")
  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/pkg_resources.py", line 2645, in scan_list
    raise ValueError(msg, line, "at", line[p:])
ValueError: ('Expected version spec in', '-r/home/travis/build/nicoddemus/pytest-plugs/.work/pytest-splinter-1.2.7/requirements-testing.txt', 'at', '/home/travis/build/nicoddemus/pytest-plugs/.work/pytest-splinter-1.2.7/requirements-testing.txt')


Time: 0.5 seconds

Examples:

http://pytest-plugs.herokuapp.com/output/pytest-splinter-1.2.7?py=py27&pytest=2.6.4
http://pytest-plugs.herokuapp.com/output/pytest-benchmark-1.1.0?py=py27&pytest=2.6.4
http://pytest-plugs.herokuapp.com/output/pytest-config-0.0.11?py=py27&pytest=2.6.4

Hi. I think it would be beneficial to have a 'running locally' guide for developers to show them how to run this application locally on their machines. Does such a guide exist? If not, could one be written?

I could attempt to write one and submit it as a pr, but I'm unfamiliar with this project so I'm not sure how accurate it would be.

Follow up to pytest-dev/pytest-cov#254 (comment)

Currently, plugincompat uses a heuristic that plugins are all named with a "pytest-" prefix. However, the plugin API allows any package to advertise itself as a plugin by exposing a suitable entry point. As a result, some projects which have useful plugins aren't included (e.g. backports.unittest_mock or jaraco.mongodb). I guess one could just create a slim wrapper around those in another package called "pytest-backports-unittest-mock" or similar, but that seems messy.

Furethermore, some packages like pytest-runner aren't pytest plugins, but appear to be so according to the heuristic.

How about instead considering a technique whereby a project can declare it's "Pytest Plugin-ness" through package metadata? Since entry points aren't readily visible in package metadata, perhaps consider creating a Trove Classifier to authoritatively and cleanly indicate the presence of a pytest plugin?

Is there a reason? What if author want to publish bdist_wheel only?
Just curious (and perhaps it could be mentioned in readme that you must upload an sdist to index)