p53209761
/
test_ok2
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
test_ok2/pyproject.toml

57 lines
1.2 KiB
TOML
Raw Normal View History

add build-system section to pyproject.toml this makes the file valid and prepares for https://github.com/pypa/pip/issues/5416 and https://github.com/pypa/pip/pull/5512
2018-06-19 16:41:04 +08:00
[build-system]
requires = [
modernize packaging for setuptools>30.3
2018-10-15 03:44:32 +08:00
# sync with setup.py until we discard non-pep-517/518
fix #4177 - pin setuptools>=40.0
2018-10-18 02:08:07 +08:00
"setuptools>=40.0",
add build-system section to pyproject.toml this makes the file valid and prepares for https://github.com/pypa/pip/issues/5416 and https://github.com/pypa/pip/pull/5512
2018-06-19 16:41:04 +08:00
"setuptools-scm",
"wheel",
]
Use isolated_build option in tox.ini As per the excellent article by gaborbernat: https://www.bernat.tech/pep-517-518/
2019-02-09 01:50:33 +08:00
build-backend = "setuptools.build_meta"
add build-system section to pyproject.toml this makes the file valid and prepares for https://github.com/pypa/pip/issues/5416 and https://github.com/pypa/pip/pull/5512
2018-06-19 16:41:04 +08:00
switch changelog management to towncrier
2017-05-30 21:54:15 +08:00
[tool.towncrier]
package = "pytest"
Configure towncrier to use src directory
2018-06-05 09:01:23 +08:00
package_dir = "src"
docs: move changelog to docs/en and allow sphinx directives Now `tox -e docs` will also include the draft changelog for the next version (locally only). `CHANGELOG.rst` now only points to the changelog on READTHEDOCS so sphinx diretives can be used. Followup to https://github.com/pytest-dev/pytest/pull/6272
2019-11-25 11:06:30 +08:00
filename = "doc/en/changelog.rst"
switch changelog management to towncrier
2017-05-30 21:54:15 +08:00
directory = "changelog/"
Use "pytest" on the CHANGELOG
2018-07-27 20:21:18 +08:00
title_format = "pytest {version} ({project_date})"
switch changelog management to towncrier
2017-05-30 21:54:15 +08:00
template = "changelog/_template.rst"
[[tool.towncrier.type]]
Replace 'removal' by 'breaking' changelog category As discussed, sometimes we will need to introduce changes which are not necessarily removals but might break existing suites
2019-12-06 19:47:39 +08:00
directory = "breaking"
name = "Breaking Changes"
Separate deprecations and removals in the CHANGELOG
2018-09-14 01:02:01 +08:00
showcontent = true
[[tool.towncrier.type]]
directory = "deprecation"
name = "Deprecations"
switch changelog management to towncrier
2017-05-30 21:54:15 +08:00
showcontent = true
[[tool.towncrier.type]]
directory = "feature"
name = "Features"
showcontent = true
Add new 'improvement' changelog category This creates a separate section from 'features' for small changes which don't usually require user intervention, such as: * Human readable session duration * New junitxml fields * Improved colors in terminal * etc. The idea is to better match user expectations about new actual features in the "Features" section of the changelog.
2019-08-10 20:26:37 +08:00
[[tool.towncrier.type]]
directory = "improvement"
name = "Improvements"
showcontent = true
switch changelog management to towncrier
2017-05-30 21:54:15 +08:00
[[tool.towncrier.type]]
directory = "bugfix"
name = "Bug Fixes"
showcontent = true
[[tool.towncrier.type]]
directory = "vendor"
name = "Vendored Libraries"
showcontent = true
[[tool.towncrier.type]]
directory = "doc"
name = "Improved Documentation"
showcontent = true
[[tool.towncrier.type]]
directory = "trivial"
Show "trivial" category in CHANGELOG I think it might sense to display in the CHANGELOG internal or trivial changes because they might trip users between releases. For example, a note about an internal refactoring (like moving a class between modules) is useful for a user that has been using the internal API. Of course we are not breaking anything because it was an internal API, but no reason not to save time for users who did use it.
2017-06-23 23:30:29 +08:00
name = "Trivial/Internal Changes"
showcontent = true