Bump pytest-doctestplus from 0.4.0 to 0.9.0

[dependabot]

Bumps pytest-doctestplus from 0.4.0 to 0.9.0.

Release notes

Sourced from pytest-doctestplus's releases.

0.9.0 Release Notes

• Declare setuptools runtime dependency. #93
• Add SHOW_WARNINGS flag to show warnings. #136
• Add the doctestplus sphinx extension. #113
• Compatibility with pytest>=6.3 [Add tree #140, #141]

0.8.0 Release Notes

New changes since 0.7.0:

• Compatibility with pytest 6.0.0. #120

Changelog

Sourced from pytest-doctestplus's changelog.

0.9.0 (2021-01-14)

• Declare setuptools runtime dependency #93

• Add SHOW_WARNINGS flag to show warnings. #136

• Add the doctestplus sphinx extension. #113

• Compatibility with pytest>=6.3 [Add tree #140, #141]

0.8.0 (2020-07-31)

• Compatibility with pytest 6.0.0. #120

0.7.0 (2020-05-20)

• Added a new ini option, doctest_subpackage_requires, that can be used to skip specific subpackages based on required packages. #112

0.6.1 (2020-05-04)

• Disabling the usage of the doctest_ignore_import_errors option to ensure no behaviour changes compared to the 0.5.0 release. #108

0.6.0 (2020-04-30)

• Drop support for python versions earlier than 3.6. #103

• Drop support for pytest versions earlier than 4.0. #103

• Fix compatibility with pytest 5.4. #103

0.5.0 (2019-11-15)

• No longer require Numpy. #69

• Fixed a bug that caused __doctest_requires__ to not work correctly with submodules. #73

• Fixed a limitation that meant that ELLIPSIS and FLOAT_CMP could not be used at the same time. #75

... (truncated)

Commits

• 2c12649 Release 0.9.0
• 37721eb Merge pull request #144 from pllim/twine-3.3-strict
• 4292dcc Put quotes around pip pinning
• a296154 Pin twine version in workflow.
• 280ccc4 MNT: Use --strict in twine check
• 6abc0bf Merge pull request #143 from saimn/changelog
• 7afc4c1 Update CHANGES
• 31c5026 Merge pull request #139 from saimn/publish
• 881dfbc Add long_description_content_type
• 1073a47 Try master
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[pep8speaks]

Hello @dependabot[bot]! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2021-06-18 06:10:12 UTC

[joshmoore]

Note that edc8b25 needed to disable bench/compress_normal.py since an update of line_profiler is leading to an odd failure (variable a is not being found)

Perhaps this could be updated with something that benchmarks on each commit? (@jacksonmaxfield?)

[evamaxfield]

@joshmoore we could setup asv for "deep benchmarking". it requires a bit of complexity however. Most of the scipy libs that use it have a whole other repo for just asv. It may be good to add it to the zarr-impls repo in which case?

[joshmoore]

Can definitely see having an extra repository for it. If it were in zarr_implementations then that would apply we'd track the performance for the small number of tests (currently 1) for all implementations, rather than a number of tests for this one repo, right?

[evamaxfield]

Yea I would say adding benchmarks for all impls would be great but since they are in other languages it would be weird to benchmark a subprocess... Hmmm. Maybe need to think.

[joshmoore]

Captured the remaining issue as #785