Menu
▾
▴
docutils-develop — For developer discussions of the implementation.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(27) |
Jun
(22) |
Jul
(72) |
Aug
(82) |
Sep
(86) |
Oct
(138) |
Nov
(100) |
Dec
(62) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(122) |
Feb
(147) |
Mar
(92) |
Apr
(82) |
May
(101) |
Jun
(153) |
Jul
(37) |
Aug
(34) |
Sep
(46) |
Oct
(46) |
Nov
(6) |
Dec
(38) |
| 2004 |
Jan
(64) |
Feb
(81) |
Mar
(36) |
Apr
(194) |
May
(329) |
Jun
(272) |
Jul
(68) |
Aug
(74) |
Sep
(150) |
Oct
(57) |
Nov
(62) |
Dec
(63) |
| 2005 |
Jan
(78) |
Feb
(30) |
Mar
(137) |
Apr
(78) |
May
(54) |
Jun
(122) |
Jul
(72) |
Aug
(110) |
Sep
(80) |
Oct
(75) |
Nov
(125) |
Dec
(79) |
| 2006 |
Jan
(100) |
Feb
(15) |
Mar
(41) |
Apr
(67) |
May
(30) |
Jun
(11) |
Jul
(14) |
Aug
(22) |
Sep
(20) |
Oct
(14) |
Nov
(11) |
Dec
(15) |
| 2007 |
Jan
(17) |
Feb
(16) |
Mar
(35) |
Apr
(21) |
May
(33) |
Jun
(50) |
Jul
(12) |
Aug
(7) |
Sep
(2) |
Oct
(6) |
Nov
(5) |
Dec
(2) |
| 2008 |
Jan
(14) |
Feb
(20) |
Mar
(35) |
Apr
(9) |
May
(57) |
Jun
(21) |
Jul
(42) |
Aug
(4) |
Sep
(13) |
Oct
(76) |
Nov
(40) |
Dec
(55) |
| 2009 |
Jan
(26) |
Feb
(15) |
Mar
(3) |
Apr
(67) |
May
(32) |
Jun
(39) |
Jul
(59) |
Aug
(31) |
Sep
(59) |
Oct
(64) |
Nov
(21) |
Dec
(10) |
| 2010 |
Jan
(21) |
Feb
(3) |
Mar
(116) |
Apr
(33) |
May
(9) |
Jun
(28) |
Jul
(21) |
Aug
(23) |
Sep
(146) |
Oct
(70) |
Nov
(31) |
Dec
(57) |
| 2011 |
Jan
(33) |
Feb
(22) |
Mar
(11) |
Apr
(21) |
May
(51) |
Jun
(47) |
Jul
(35) |
Aug
(26) |
Sep
(25) |
Oct
(34) |
Nov
(61) |
Dec
(51) |
| 2012 |
Jan
(75) |
Feb
(31) |
Mar
(26) |
Apr
(16) |
May
(24) |
Jun
(24) |
Jul
(31) |
Aug
(46) |
Sep
(36) |
Oct
(28) |
Nov
(37) |
Dec
(21) |
| 2013 |
Jan
(16) |
Feb
(56) |
Mar
(31) |
Apr
(44) |
May
(45) |
Jun
(29) |
Jul
(38) |
Aug
(18) |
Sep
(12) |
Oct
(16) |
Nov
(21) |
Dec
(11) |
| 2014 |
Jan
(13) |
Feb
(14) |
Mar
(28) |
Apr
(7) |
May
(72) |
Jun
(33) |
Jul
(21) |
Aug
(1) |
Sep
(6) |
Oct
(14) |
Nov
(18) |
Dec
(22) |
| 2015 |
Jan
(23) |
Feb
(108) |
Mar
(76) |
Apr
(114) |
May
(60) |
Jun
(9) |
Jul
(8) |
Aug
(9) |
Sep
(42) |
Oct
(9) |
Nov
|
Dec
(7) |
| 2016 |
Jan
(6) |
Feb
(15) |
Mar
(7) |
Apr
|
May
(33) |
Jun
(3) |
Jul
(19) |
Aug
(12) |
Sep
(6) |
Oct
(16) |
Nov
(17) |
Dec
(125) |
| 2017 |
Jan
(66) |
Feb
(98) |
Mar
(29) |
Apr
(32) |
May
(63) |
Jun
(98) |
Jul
(26) |
Aug
(33) |
Sep
(19) |
Oct
(77) |
Nov
(31) |
Dec
(27) |
| 2018 |
Jan
(32) |
Feb
(11) |
Mar
(5) |
Apr
(12) |
May
(4) |
Jun
(9) |
Jul
(9) |
Aug
(13) |
Sep
(11) |
Oct
(6) |
Nov
(23) |
Dec
(2) |
| 2019 |
Jan
(26) |
Feb
(12) |
Mar
(20) |
Apr
(18) |
May
(7) |
Jun
(22) |
Jul
(81) |
Aug
(129) |
Sep
(32) |
Oct
(18) |
Nov
(11) |
Dec
(44) |
| 2020 |
Jan
(19) |
Feb
(10) |
Mar
(38) |
Apr
(4) |
May
(9) |
Jun
(15) |
Jul
(29) |
Aug
(79) |
Sep
(12) |
Oct
(22) |
Nov
(10) |
Dec
(37) |
| 2021 |
Jan
(16) |
Feb
(14) |
Mar
(20) |
Apr
(100) |
May
(21) |
Jun
(19) |
Jul
(13) |
Aug
(13) |
Sep
(37) |
Oct
(112) |
Nov
(64) |
Dec
(22) |
| 2022 |
Jan
(209) |
Feb
(38) |
Mar
(11) |
Apr
(10) |
May
(55) |
Jun
(104) |
Jul
(35) |
Aug
(10) |
Sep
(21) |
Oct
(21) |
Nov
(50) |
Dec
(12) |
| 2023 |
Jan
(6) |
Feb
|
Mar
(3) |
Apr
(41) |
May
(48) |
Jun
(9) |
Jul
(6) |
Aug
(25) |
Sep
(3) |
Oct
(22) |
Nov
(56) |
Dec
(12) |
| 2024 |
Jan
(5) |
Feb
(5) |
Mar
(38) |
Apr
(62) |
May
(12) |
Jun
(10) |
Jul
(3) |
Aug
(59) |
Sep
(2) |
Oct
(36) |
Nov
(14) |
Dec
(3) |
| 2025 |
Jan
(5) |
Feb
(19) |
Mar
(7) |
Apr
(65) |
May
(11) |
Jun
(13) |
Jul
(46) |
Aug
(17) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Adam T. <aa-...@us...> - 2022-01-05 16:14:00
|
>we can drop the "install in development mode with setuptools" route Yep, I already applied that in my patch. pip has done editable installs via `setup.py` basically forever. The new thing was editable installs with build backends that are not `setuptools` -- that is what was added in pip 21.3. The current patch (moving to declarative metadata but keeping setuptools) therefore meets all of these critera, I think. A --- ** [patches:#186] Modernise packaging** **Status:** open **Group:** None **Created:** Fri Dec 31, 2021 03:16 AM UTC by Adam Turner **Last Updated:** Wed Jan 05, 2022 03:26 PM UTC **Owner:** nobody **Attachments:** - [0001-Use-flit-and-pyproject.toml.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0001-Use-flit-and-pyproject.toml.patch) (12.2 kB; application/octet-stream) - [0002-Use-entry-points.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0002-Use-entry-points.patch) (20.7 kB; application/octet-stream) - [0003-update-docs-etc-after-packaging-changes.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0003-update-docs-etc-after-packaging-changes.patch) (49.3 kB; application/octet-stream) Hi, I had a go at modernising the packaging stack. `setup.py` based invocations have been deprecated (https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html), and setuptools may remove them in the future. This takes the opportunity to move to a PEP 621 based declarative config, and also fixes a longstanding TODO item about providing script wappers for the frontend tools on windows, by migrating them to entry points. I've updated install and development docs with the new guidance, and updated references to the frontend tools to remove `.py`, given they are now installed as proper scripts. Hope this is appreciated -- happy to make revisions etc to help getting this merged. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Günter M. <mi...@us...> - 2022-01-05 15:26:45
|
If a current, stable pip does editable installs, we can drop the "install in development mode with setuptools" route. Requiring a recent pip should be acceptable for developers (and other users prefering an editable install), given that "manual" install is still possible for the "diehards". A standard install should remain possible from, e.g., Debian without further non-system dependencies after any change. If pip 20.3.4 suffices for a standard install without "setup.py" and if we can install the front-end tools under their current names, I am fine with a change of the build system. --- ** [patches:#186] Modernise packaging** **Status:** open **Group:** None **Created:** Fri Dec 31, 2021 03:16 AM UTC by Adam Turner **Last Updated:** Wed Jan 05, 2022 02:37 PM UTC **Owner:** nobody **Attachments:** - [0001-Use-flit-and-pyproject.toml.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0001-Use-flit-and-pyproject.toml.patch) (12.2 kB; application/octet-stream) - [0002-Use-entry-points.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0002-Use-entry-points.patch) (20.7 kB; application/octet-stream) - [0003-update-docs-etc-after-packaging-changes.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0003-update-docs-etc-after-packaging-changes.patch) (49.3 kB; application/octet-stream) Hi, I had a go at modernising the packaging stack. `setup.py` based invocations have been deprecated (https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html), and setuptools may remove them in the future. This takes the opportunity to move to a PEP 621 based declarative config, and also fixes a longstanding TODO item about providing script wappers for the frontend tools on windows, by migrating them to entry points. I've updated install and development docs with the new guidance, and updated references to the frontend tools to remove `.py`, given they are now installed as proper scripts. Hope this is appreciated -- happy to make revisions etc to help getting this merged. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Adam T. <aa-...@us...> - 2022-01-05 14:37:49
|
@milde Updated in https://github.com/AA-Turner/docutils/pull/1 // https://github.com/AA-Turner/docutils/pull/1.patch This now just uses setup.cfg based metadata, and is a substantially smaller change. I also added the putative docutils-cli package to hold the front-end entrypoints. A --- ** [patches:#186] Modernise packaging** **Status:** open **Group:** None **Created:** Fri Dec 31, 2021 03:16 AM UTC by Adam Turner **Last Updated:** Wed Jan 05, 2022 11:51 AM UTC **Owner:** nobody **Attachments:** - [0001-Use-flit-and-pyproject.toml.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0001-Use-flit-and-pyproject.toml.patch) (12.2 kB; application/octet-stream) - [0002-Use-entry-points.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0002-Use-entry-points.patch) (20.7 kB; application/octet-stream) - [0003-update-docs-etc-after-packaging-changes.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0003-update-docs-etc-after-packaging-changes.patch) (49.3 kB; application/octet-stream) Hi, I had a go at modernising the packaging stack. `setup.py` based invocations have been deprecated (https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html), and setuptools may remove them in the future. This takes the opportunity to move to a PEP 621 based declarative config, and also fixes a longstanding TODO item about providing script wappers for the frontend tools on windows, by migrating them to entry points. I've updated install and development docs with the new guidance, and updated references to the frontend tools to remove `.py`, given they are now installed as proper scripts. Hope this is appreciated -- happy to make revisions etc to help getting this merged. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Adam T. <aa-...@us...> - 2022-01-05 11:51:44
|
> What I have in mind is a "manual install" Ahh, yes then that will continue to work -- sorry, I had thought you meant using some tool in Python's stdlib. > Names and arguments of the commands ... are part of Docutils' public API (cf. PEP 387). I agree. My proposal isn't to remove them with no recourse, but to deprecate over a period of time, clearly marking identical drop-in commands at runtime to affected users. Yes we cannot know how many people would be affected with local random scripts, but it is a two-second change. Many users will also run with old or pinned versions of Docutils, and part of updating is seeing the changelog. If Debian or other redistributors already make changes, they could decide to keep shell aliases from `rst2*` to the new `docutils-cli` based invocations. > "entry point" for the benefit of Windows users seams feasible. Entrypoints aren't just for the benefits of Windows users -- they are a standards based tool, whereas copying files from a directory straight onto PATH isn't -- setuptools just has that feature as an accident of history. > My suggested timeline ... By developer consensus I imagine you mean amongst yourself & Englebert? I don't know if there are any other active maintainers on the project (I don't know if you're looking for new maintainers?) New suggested changes below: Move to declarative metadata using `setuptools`. I had wanted to avoid this as they use `setup.cfg` for metadata (support for PEP 621 metadata is planned but not implemented). This has no other implications, as all setuptools based behaviour remains. Add deprecation notices where relevant Introduce a new package `docutils-cli` that contains entrypoints etc -- acting as a thin wrapper over `docutils`. CLI based functionality could then move to the `docutils-cli` package per the rest of the timeline as you suggest. I'll update my patch accordingly, and will post it when done. --- ** [patches:#186] Modernise packaging** **Status:** open **Group:** None **Created:** Fri Dec 31, 2021 03:16 AM UTC by Adam Turner **Last Updated:** Wed Jan 05, 2022 11:35 AM UTC **Owner:** nobody **Attachments:** - [0001-Use-flit-and-pyproject.toml.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0001-Use-flit-and-pyproject.toml.patch) (12.2 kB; application/octet-stream) - [0002-Use-entry-points.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0002-Use-entry-points.patch) (20.7 kB; application/octet-stream) - [0003-update-docs-etc-after-packaging-changes.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0003-update-docs-etc-after-packaging-changes.patch) (49.3 kB; application/octet-stream) Hi, I had a go at modernising the packaging stack. `setup.py` based invocations have been deprecated (https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html), and setuptools may remove them in the future. This takes the opportunity to move to a PEP 621 based declarative config, and also fixes a longstanding TODO item about providing script wappers for the frontend tools on windows, by migrating them to entry points. I've updated install and development docs with the new guidance, and updated references to the frontend tools to remove `.py`, given they are now installed as proper scripts. Hope this is appreciated -- happy to make revisions etc to help getting this merged. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Adam T. <aa-...@us...> - 2022-01-05 11:35:16
|
> Will (editable) installs also work without setup.py when using pip 20.3.4 (the version in current Debian/stable) ? Editable installs through the new standardised mechanism (PEP 660) require pip 21.3 or newer. This can be installed on any system with `python -m install --upgdade pip`. If 20.3.4 is in Debian, that is 2 years old at this point, but yes it would require updating. Upgrading pip is always recommeded (see the warning every time you run with an old version of pip) -- some redistributors include rather old versions. A --- ** [patches:#186] Modernise packaging** **Status:** open **Group:** None **Created:** Fri Dec 31, 2021 03:16 AM UTC by Adam Turner **Last Updated:** Wed Jan 05, 2022 09:53 AM UTC **Owner:** nobody **Attachments:** - [0001-Use-flit-and-pyproject.toml.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0001-Use-flit-and-pyproject.toml.patch) (12.2 kB; application/octet-stream) - [0002-Use-entry-points.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0002-Use-entry-points.patch) (20.7 kB; application/octet-stream) - [0003-update-docs-etc-after-packaging-changes.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0003-update-docs-etc-after-packaging-changes.patch) (49.3 kB; application/octet-stream) Hi, I had a go at modernising the packaging stack. `setup.py` based invocations have been deprecated (https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html), and setuptools may remove them in the future. This takes the opportunity to move to a PEP 621 based declarative config, and also fixes a longstanding TODO item about providing script wappers for the frontend tools on windows, by migrating them to entry points. I've updated install and development docs with the new guidance, and updated references to the frontend tools to remove `.py`, given they are now installed as proper scripts. Hope this is appreciated -- happy to make revisions etc to help getting this merged. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Günter M. <mi...@us...> - 2022-01-05 09:53:27
|
My suggested timeline regarding the front-end tools is: - Get a clear picture of intended changes and their consequences (good and bad). - Wait for developer consensus. - Implement non intrusive, backwards compatible changes. - Announce upcoming changes. - release 0.19 - Add entrypoint for `docutils-cli` (maybe called `docutils`). - Retain `*.py` files in tools/ and keep providing them under the established name in the PATH (either copying or via entry-points). - Add deprecation notice in RELEASE-NOTES and docs/usr/tools. Change usage examples in the documentation. - release 1.0 - Announce deprecation of rst2*.py commands at runtime (the deprecation message contains the replacement invocation needed, this may be a `docutils` command with options or more specific helpers from a new "docutils-cli" package). The replacement invocation must be fixed and implementd at the time we start to nag users. - release 1.1 - Cease installing rst2*.py tools in the PATH - Eventually provide a separate "docutils-cli" package which may include moving the generic `docutils` front-end tool there and/or providing the special tools as `rst2*` or`rst2*.py`. - release 1.2 --- ** [patches:#186] Modernise packaging** **Status:** open **Group:** None **Created:** Fri Dec 31, 2021 03:16 AM UTC by Adam Turner **Last Updated:** Tue Jan 04, 2022 11:34 PM UTC **Owner:** nobody **Attachments:** - [0001-Use-flit-and-pyproject.toml.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0001-Use-flit-and-pyproject.toml.patch) (12.2 kB; application/octet-stream) - [0002-Use-entry-points.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0002-Use-entry-points.patch) (20.7 kB; application/octet-stream) - [0003-update-docs-etc-after-packaging-changes.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0003-update-docs-etc-after-packaging-changes.patch) (49.3 kB; application/octet-stream) Hi, I had a go at modernising the packaging stack. `setup.py` based invocations have been deprecated (https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html), and setuptools may remove them in the future. This takes the opportunity to move to a PEP 621 based declarative config, and also fixes a longstanding TODO item about providing script wappers for the frontend tools on windows, by migrating them to entry points. I've updated install and development docs with the new guidance, and updated references to the frontend tools to remove `.py`, given they are now installed as proper scripts. Hope this is appreciated -- happy to make revisions etc to help getting this merged. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Tomasz Kło. <kl...@us...> - 2022-01-05 05:50:05
|
BTW latest pytest shows some deprecation warnings
~~~
============================================================================= warnings summary =============================================================================
test/test_parsers/test_recommonmark/test_section_headers.py:37
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_parsers/test_recommonmark/test_section_headers.py:37: DeprecationWarning: invalid escape sequence \
"""\
test/test_parsers/test_recommonmark/test_section_headers.py:50
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_parsers/test_recommonmark/test_section_headers.py:50: DeprecationWarning: invalid escape sequence \
"""\
test/test_parsers/test_recommonmark/test_section_headers.py:164
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_parsers/test_recommonmark/test_section_headers.py:164: DeprecationWarning: invalid escape sequence \
"""\
test/test_transforms/test___init__.py:20
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_transforms/test___init__.py:20: PytestCollectionWarning: cannot collect test class 'TestTransform' because it has a __init__ constructor (from: test/test_transforms/test___init__.py)
class TestTransform(transforms.Transform):
test/test_settings.py::ConfigFileTests::test_old
test/test_settings.py::ConfigFileTests::test_old_and_new
test/test_settings.py::ConfigEnvVarFileTests::test_old
test/test_settings.py::ConfigEnvVarFileTests::test_old_and_new
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/data/config_old.txt:0: ConfigDeprecationWarning:
The "[option]" section is deprecated. Support for old-format configuration
files may be removed in a future Docutils release. Please revise your
configuration files. See <http://docutils.sf.net/docs/user/config.html>,
section "Old-Format Configuration Files".
-- Docs: https://docs.pytest.org/en/stable/warnings.html
========================================================================= short test summary info ==========================================================================
SKIPPED [1] test/test_parsers/test_recommonmark/test_misc.py:81: optional module "recommonmark" not found
SKIPPED [1] test/test_parsers/test_recommonmark/test_misc.py:70: optional module "recommonmark" not found
========================================================= 227 passed, 2 skipped, 9 deselected, 8 warnings in 3.28s =========================================================
~~~
---
** [feature-requests:#81] 0.17.1: pytest is failing**
**Status:** open
**Group:**
**Created:** Sun Jun 27, 2021 03:07 AM UTC by Tomasz Kłoczko
**Last Updated:** Wed Jan 05, 2022 05:48 AM UTC
**Owner:** nobody
Just normal build, install and test cycle used on building package from non-root account:
- "setup.py build"
- "setup.py install --root </install/prefix>"
- "pytest with PYTHONPATH pointing to setearch and sitelib inside </install/prefix>
~~~
+ PYTHONPATH=/home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages
+ PYTHONDONTWRITEBYTECODE=1
+ /usr/bin/pytest -ra
=========================================================================== test session starts ============================================================================
platform linux -- Python 3.8.9, pytest-6.2.4, py-1.10.0, pluggy-0.13.1
benchmark: 3.4.1 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.000005 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=100000)
Using --randomly-seed=2664516846
rootdir: /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1
plugins: forked-1.3.0, shutil-1.7.0, virtualenv-1.7.0, expect-1.1.0, httpbin-1.0.0, flake8-1.0.7, timeout-1.4.2, betamax-0.8.1, freezegun-0.4.2, case-1.5.3, isort-1.3.0, aspectlib-1.5.2, asyncio-0.15.1, toolbox-0.5, xprocess-0.17.1, aiohttp-0.3.0, checkdocs-2.7.0, mock-3.6.1, rerunfailures-9.1.1, requests-mock-1.9.3, cov-2.12.1, pyfakefs-4.5.0, cases-3.6.1, flaky-3.7.0, hypothesis-6.14.0, benchmark-3.4.1, xdist-2.3.0, pylama-7.7.1, randomly-3.8.0, Faker-8.8.2, datadir-1.3.1, regressions-2.2.0
collected 240 items
test/test_statemachine.py ................. [ 7%]
test/test_functional.py E [ 7%]
test/test_dependencies.py ..... [ 9%]
test/test_parsers/test_get_parser_class.py ... [ 10%]
test/test_writers/test_latex2e_misc.py . [ 11%]
test/test_publisher.py .... [ 12%]
test/test_writers/test_get_writer_class.py ... [ 14%]
test/test__init__.py .. [ 15%]
. . [ 15%]
test/test__init__.py ...... [ 17%]
test/test_settings.py ........................ [ 28%]
test/test_writers/test_docutils_xml.py ..... [ 30%]
test/test_parsers/test_parser.py . [ 30%]
test/test_transforms/test___init__.py . [ 30%]
test/test_language.py EEEE [ 32%]
test/test_traversals.py . [ 33%]
test/test_writers/test_odt.py .......... [ 37%]
test/test_command_line.py F [ 37%]
test/test_writers/test_html5_polyglot_parts.py EE [ 38%]
test/test_nodes.py ............................... [ 51%]
test/test_writers/test_html5_polyglot_misc.py ............... [ 57%]
test/test_pickle.py . [ 58%]
tools/test/test_buildhtml.py .. [ 58%]
test/test_io.py ................. [ 66%]
test/test_readers/test_get_reader_class.py ... [ 67%]
test/test_error_reporting.py ............. [ 72%]
test/test_writers/test_html4css1_misc.py ............... [ 79%]
test/test_parsers/test_rst/test_directives/test_code_parsing.py .. [ 79%]
test/test_utils.py ........................ [ 89%]
test/test_parsers/test_recommonmark/test_misc.py ..Fs [ 91%]
test/test_parsers/test_rst/test_directives/test__init__.py .... [ 93%]
test/test_viewlist.py ................ [100%]
================================================================================== ERRORS ==================================================================================
________________________________________________________________ ERROR at setup of FunctionalTestCase.test _________________________________________________________________
self = <[AttributeError("'FunctionalTestCase' object has no attribute '_testMethodName'") raised in repr()] FunctionalTestCase object at 0x7fbd75666df0>, args = ('test',)
kwargs = {}
def __init__(self, *args, **kwargs):
"""Set self.configfile, pass arguments to parent __init__."""
> self.configfile = kwargs['configfile']
E KeyError: 'configfile'
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_functional.py:95: KeyError
____________________________________________________________ ERROR at setup of LanguageTestCase.test_directives ____________________________________________________________
self = <[AttributeError("'LanguageTestCase' object has no attribute '_testMethodName'") raised in repr()] LanguageTestCase object at 0x7fbd754ce0d0>
args = ('test_directives',), kwargs = {}
def __init__(self, *args, **kwargs):
self.ref = docutils.languages.get_language(reference_language,
_reporter)
> self.language = kwargs['language']
E KeyError: 'language'
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_language.py:81: KeyError
______________________________________________________________ ERROR at setup of LanguageTestCase.test_roles _______________________________________________________________
self = <[AttributeError("'LanguageTestCase' object has no attribute '_testMethodName'") raised in repr()] LanguageTestCase object at 0x7fbd753f98b0>, args = ('test_roles',)
kwargs = {}
def __init__(self, *args, **kwargs):
self.ref = docutils.languages.get_language(reference_language,
_reporter)
> self.language = kwargs['language']
E KeyError: 'language'
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_language.py:81: KeyError
_______________________________________________________ ERROR at setup of LanguageTestCase.test_bibliographic_fields _______________________________________________________
self = <[AttributeError("'LanguageTestCase' object has no attribute '_testMethodName'") raised in repr()] LanguageTestCase object at 0x7fbd753c4850>
args = ('test_bibliographic_fields',), kwargs = {}
def __init__(self, *args, **kwargs):
self.ref = docutils.languages.get_language(reference_language,
_reporter)
> self.language = kwargs['language']
E KeyError: 'language'
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_language.py:81: KeyError
______________________________________________________________ ERROR at setup of LanguageTestCase.test_labels ______________________________________________________________
self = <[AttributeError("'LanguageTestCase' object has no attribute '_testMethodName'") raised in repr()] LanguageTestCase object at 0x7fbd754181f0>
args = ('test_labels',), kwargs = {}
def __init__(self, *args, **kwargs):
self.ref = docutils.languages.get_language(reference_language,
_reporter)
> self.language = kwargs['language']
E KeyError: 'language'
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_language.py:81: KeyError
______________________________________________________ ERROR at setup of HtmlWriterPublishPartsTestCase.test_publish _______________________________________________________
self = <[AttributeError("'HtmlWriterPublishPartsTestCase' object has no attribute '_testMethodName'") raised in repr()] HtmlWriterPublishPartsTestCase object at 0x7fbd54e7e550>
args = ('test_publish',), kwargs = {}
def __init__(self, *args, **kwargs):
if 'writer_name' in kwargs:
self.writer_name = kwargs['writer_name']
del kwargs['writer_name']
> CustomTestCase.__init__(self, *args, **kwargs)
E TypeError: __init__() missing 3 required positional arguments: 'input', 'expected', and 'id'
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/DocutilsTestSupport.py:673: TypeError
______________________________________________________ ERROR at setup of Html5WriterPublishPartsTestCase.test_publish ______________________________________________________
self = <[AttributeError("'Html5WriterPublishPartsTestCase' object has no attribute '_testMethodName'") raised in repr()] Html5WriterPublishPartsTestCase object at 0x7fbd75348160>
args = ('test_publish',), kwargs = {}
def __init__(self, *args, **kwargs):
if 'writer_name' in kwargs:
self.writer_name = kwargs['writer_name']
del kwargs['writer_name']
> CustomTestCase.__init__(self, *args, **kwargs)
E TypeError: __init__() missing 3 required positional arguments: 'input', 'expected', and 'id'
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/DocutilsTestSupport.py:673: TypeError
================================================================================= FAILURES =================================================================================
_____________________________________________________________ CommandLineEncodingTests.test_sys_argv_decoding ______________________________________________________________
self = <docutils.frontend.OptionParser object at 0x7fbd54bba550>, args = ['-ra', '--source-url=test.txt', '--title=Dornröschen']
values = <Values at 0x7fbd54bba2e0: {'title': None, 'generator': True, 'datestamp': "%Y-%m-%d %H:%M UTC (If you see this in tes..._visitor': None, '_disable_config': None, '_source': None, '_destination': None, '_config_files': ['./docutils.conf']}>
def parse_args(self, args=None, values=None):
"""
parse_args(args : [string] = sys.argv[1:],
values : Values = None)
-> (values : Values, args : [string])
Parse the command-line options found in 'args' (default:
sys.argv[1:]). Any errors result in a call to 'error()', which
by default prints the usage message to stderr and calls
sys.exit() with an error message. On success returns a pair
(values, args) where 'values' is a Values instance (with all
your option values) and 'args' is the list of arguments left
over after parsing options.
"""
rargs = self._get_args(args)
if values is None:
values = self.get_default_values()
# Store the halves of the argument list as attributes for the
# convenience of callbacks:
# rargs
# the rest of the command-line (the "r" stands for
# "remaining" or "right-hand")
# largs
# the leftover arguments -- ie. what's left after removing
# options and their arguments (the "l" stands for "leftover"
# or "left-hand")
self.rargs = rargs
self.largs = largs = []
self.values = values
try:
> stop = self._process_args(largs, rargs, values)
/usr/lib64/python3.8/optparse.py:1387:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <docutils.frontend.OptionParser object at 0x7fbd54bba550>, largs = [], rargs = ['--source-url=test.txt', '--title=Dornröschen']
values = <Values at 0x7fbd54bba2e0: {'title': None, 'generator': True, 'datestamp': "%Y-%m-%d %H:%M UTC (If you see this in tes..._visitor': None, '_disable_config': None, '_source': None, '_destination': None, '_config_files': ['./docutils.conf']}>
def _process_args(self, largs, rargs, values):
"""_process_args(largs : [string],
rargs : [string],
values : Values)
Process command-line arguments and populate 'values', consuming
options and arguments from 'rargs'. If 'allow_interspersed_args' is
false, stop at the first non-option argument. If true, accumulate any
interspersed non-option arguments in 'largs'.
"""
while rargs:
arg = rargs[0]
# We handle bare "--" explicitly, and bare "-" is handled by the
# standard arg handler since the short arg case ensures that the
# len of the opt string is greater than 1.
if arg == "--":
del rargs[0]
return
elif arg[0:2] == "--":
# process a single long option (possibly with value(s))
self._process_long_opt(rargs, values)
elif arg[:1] == "-" and len(arg) > 1:
# process a cluster of short options (possibly with
# value(s) for the last one only)
> self._process_short_opts(rargs, values)
/usr/lib64/python3.8/optparse.py:1431:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <docutils.frontend.OptionParser object at 0x7fbd54bba550>, rargs = ['--source-url=test.txt', '--title=Dornröschen']
values = <Values at 0x7fbd54bba2e0: {'title': None, 'generator': True, 'datestamp': "%Y-%m-%d %H:%M UTC (If you see this in tes..._visitor': None, '_disable_config': None, '_source': None, '_destination': None, '_config_files': ['./docutils.conf']}>
def _process_short_opts(self, rargs, values):
arg = rargs.pop(0)
stop = False
i = 1
for ch in arg[1:]:
opt = "-" + ch
option = self._short_opt.get(opt)
i += 1 # we have consumed a character
if not option:
raise BadOptionError(opt)
if option.takes_value():
# Any characters left in arg? Pretend they're the
# next arg, and stop consuming characters of arg.
if i < len(arg):
rargs.insert(0, arg[i:])
stop = True
nargs = option.nargs
if len(rargs) < nargs:
self.error(ngettext(
"%(option)s option requires %(number)d argument",
"%(option)s option requires %(number)d arguments",
nargs) % {"option": opt, "number": nargs})
elif nargs == 1:
value = rargs.pop(0)
else:
value = tuple(rargs[0:nargs])
del rargs[0:nargs]
else: # option doesn't take a value
value = None
> option.process(opt, value, values, self)
/usr/lib64/python3.8/optparse.py:1536:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <Option at 0x7fbd54edfd90: -r/--report>, opt = '-r', value = 'a'
values = <Values at 0x7fbd54bba2e0: {'title': None, 'generator': True, 'datestamp': "%Y-%m-%d %H:%M UTC (If you see this in tes..._visitor': None, '_disable_config': None, '_source': None, '_destination': None, '_config_files': ['./docutils.conf']}>
parser = <docutils.frontend.OptionParser object at 0x7fbd54bba550>
def process(self, opt, value, values, parser):
"""
Call the validator function on applicable settings and
evaluate the 'overrides' option.
Extends `optparse.Option.process`.
"""
> result = optparse.Option.process(self, opt, value, values, parser)
/home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/frontend.py:354:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <Option at 0x7fbd54edfd90: -r/--report>, opt = '-r', value = 'a'
values = <Values at 0x7fbd54bba2e0: {'title': None, 'generator': True, 'datestamp': "%Y-%m-%d %H:%M UTC (If you see this in tes..._visitor': None, '_disable_config': None, '_source': None, '_destination': None, '_config_files': ['./docutils.conf']}>
parser = <docutils.frontend.OptionParser object at 0x7fbd54bba550>
def process(self, opt, value, values, parser):
# First, convert the value(s) to the right type. Howl if any
# value(s) are bogus.
> value = self.convert_value(opt, value)
/usr/lib64/python3.8/optparse.py:779:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <Option at 0x7fbd54edfd90: -r/--report>, opt = '-r', value = 'a'
def convert_value(self, opt, value):
if value is not None:
if self.nargs == 1:
> return self.check_value(opt, value)
/usr/lib64/python3.8/optparse.py:771:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <Option at 0x7fbd54edfd90: -r/--report>, opt = '-r', value = 'a'
def check_value(self, opt, value):
checker = self.TYPE_CHECKER.get(self.type)
if checker is None:
return value
else:
> return checker(self, opt, value)
/usr/lib64/python3.8/optparse.py:766:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
option = <Option at 0x7fbd54edfd90: -r/--report>, opt = '-r', value = 'a'
def check_choice(option, opt, value):
if value in option.choices:
return value
else:
choices = ", ".join(map(repr, option.choices))
> raise OptionValueError(
_("option %s: invalid choice: %r (choose from %s)")
% (opt, value, choices))
E optparse.OptionValueError: option -r: invalid choice: 'a' (choose from 'info', '1', 'warning', '2', 'error', '3', 'severe', '4', 'none', '5')
/usr/lib64/python3.8/optparse.py:440: OptionValueError
During handling of the above exception, another exception occurred:
self = <test_command_line.CommandLineEncodingTests testMethod=test_sys_argv_decoding>
def test_sys_argv_decoding(self):
if argv_encoding == 'ascii': # cannot test
return
sys.argv.append('--source-url=test.txt') # pure ASCII argument
if sys.version_info < (3, 0):
sys.argv.append(u'--title=Dornröschen'.encode(argv_encoding))
else:
sys.argv.append(u'--title=Dornröschen')
publisher = docutils.core.Publisher()
> publisher.process_command_line()
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_command_line.py:41:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/core.py:162: in process_command_line
self.settings = option_parser.parse_args(argv)
/usr/lib64/python3.8/optparse.py:1389: in parse_args
self.error(str(err))
/usr/lib64/python3.8/optparse.py:1569: in error
self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <docutils.frontend.OptionParser object at 0x7fbd54bba550>, status = 2
msg = "pytest: error: option -r: invalid choice: 'a' (choose from 'info', '1', 'warning', '2', 'error', '3', 'severe', '4', 'none', '5')\n"
def exit(self, status=0, msg=None):
if msg:
sys.stderr.write(msg)
> sys.exit(status)
E SystemExit: 2
/usr/lib64/python3.8/optparse.py:1559: SystemExit
--------------------------------------------------------------------------- Captured stderr call ---------------------------------------------------------------------------
Usage
=====
pytest [options]
pytest: error: option -r: invalid choice: 'a' (choose from 'info', '1', 'warning', '2', 'error', '3', 'severe', '4', 'none', '5')
________________________________________________________________ reCommonMarkParserTests.test_parsing_error ________________________________________________________________
self = <test_parsers.test_recommonmark.test_misc.reCommonMarkParserTests testMethod=test_parsing_error>
@unittest.skipUnless(recommonmark_wrapper.CommonMarkParser, skip_msg)
def test_parsing_error(self):
> output = publish_string(sample1, parser_name='recommonmark',
settings_overrides={'warning_stream': ''})
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_parsers/test_recommonmark/test_misc.py:55:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/core.py:407: in publish_string
output, pub = publish_programmatically(
/home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/core.py:665: in publish_programmatically
output = pub.publish(enable_exit_status=enable_exit_status)
/home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/core.py:217: in publish
self.document = self.reader.read(self.source, self.parser,
/home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/readers/__init__.py:72: in read
self.parse()
/home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/readers/__init__.py:78: in parse
self.parser.parse(self.input, document)
/home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/parsers/recommonmark_wrapper.py:117: in parse
if node['level'] != section_level:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <section "title": <title...><paragraph...>>, key = 'level'
def __getitem__(self, key):
if isinstance(key, basestring):
> return self.attributes[key]
E KeyError: 'level'
/home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/nodes.py:652: KeyError
============================================================================= warnings summary =============================================================================
test/test_parsers/test_recommonmark/test_section_headers.py:37
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_parsers/test_recommonmark/test_section_headers.py:37: DeprecationWarning: invalid escape sequence \
"""\
test/test_parsers/test_recommonmark/test_section_headers.py:50
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_parsers/test_recommonmark/test_section_headers.py:50: DeprecationWarning: invalid escape sequence \
"""\
test/test_parsers/test_recommonmark/test_section_headers.py:164
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_parsers/test_recommonmark/test_section_headers.py:164: DeprecationWarning: invalid escape sequence \
"""\
test/test_transforms/test___init__.py:20
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_transforms/test___init__.py:20: PytestCollectionWarning: cannot collect test class 'TestTransform' because it has a __init__ constructor (from: test/test_transforms/test___init__.py)
class TestTransform(transforms.Transform):
test/test_settings.py::ConfigFileTests::test_old
test/test_settings.py::ConfigFileTests::test_old_and_new
test/test_settings.py::ConfigEnvVarFileTests::test_old_and_new
test/test_settings.py::ConfigEnvVarFileTests::test_old
/home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/data/config_old.txt:0: ConfigDeprecationWarning:
The "[option]" section is deprecated. Support for old-format configuration
files may be removed in a future Docutils release. Please revise your
configuration files. See <http://docutils.sf.net/docs/user/config.html>,
section "Old-Format Configuration Files".
test/test_parsers/test_recommonmark/test_misc.py::reCommonMarkParserTests::test_raw_disabled_inline
test/test_parsers/test_recommonmark/test_misc.py::reCommonMarkParserTests::test_raw_disabled
test/test_parsers/test_recommonmark/test_misc.py::reCommonMarkParserTests::test_parsing_error
/usr/lib/python3.8/site-packages/recommonmark/parser.py:75: UserWarning: Container node skipped: type=document
warn("Container node skipped: type={0}".format(mdnode.t))
-- Docs: https://docs.pytest.org/en/stable/warnings.html
========================================================================= short test summary info ==========================================================================
SKIPPED [1] test/test_parsers/test_recommonmark/test_misc.py:91: recommonmark_wrapper: parser found, fallback not used
ERROR test/test_functional.py::FunctionalTestCase::test - KeyError: 'configfile'
ERROR test/test_language.py::LanguageTestCase::test_directives - KeyError: 'language'
ERROR test/test_language.py::LanguageTestCase::test_roles - KeyError: 'language'
ERROR test/test_language.py::LanguageTestCase::test_bibliographic_fields - KeyError: 'language'
ERROR test/test_language.py::LanguageTestCase::test_labels - KeyError: 'language'
ERROR test/test_writers/test_html5_polyglot_parts.py::HtmlWriterPublishPartsTestCase::test_publish - TypeError: __init__() missing 3 required positional arguments: 'inpu...
ERROR test/test_writers/test_html5_polyglot_parts.py::Html5WriterPublishPartsTestCase::test_publish - TypeError: __init__() missing 3 required positional arguments: 'inp...
FAILED test/test_command_line.py::CommandLineEncodingTests::test_sys_argv_decoding - SystemExit: 2
FAILED test/test_parsers/test_recommonmark/test_misc.py::reCommonMarkParserTests::test_parsing_error - KeyError: 'level'
===================================================== 2 failed, 229 passed, 1 skipped, 11 warnings, 7 errors in 10.64s =====================================================
~~~
---
Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Tomasz Kło. <kl...@us...> - 2022-01-05 05:48:22
|
> Docutils testing builds on the included batteries, there is no support for the 3rd party "pytest" framework. docutils uses unittest module and pytest can handle unittrst units .. +/- some issues with units code which in ths case has been exposed. And about topic od the github/gitlab .. it would be good to migrate man VCS to one of those sites because they are offering to downlaod exact commit as patch over REST https interface. sf.net sdoes not offer that. This is extreamly useful on dowloading parches by build automation. In other words without such interface on top of the VCS such interraction is not possible. --- ** [feature-requests:#81] 0.17.1: pytest is failing** **Status:** open **Group:** **Created:** Sun Jun 27, 2021 03:07 AM UTC by Tomasz Kłoczko **Last Updated:** Wed Sep 01, 2021 06:53 PM UTC **Owner:** nobody Just normal build, install and test cycle used on building package from non-root account: - "setup.py build" - "setup.py install --root </install/prefix>" - "pytest with PYTHONPATH pointing to setearch and sitelib inside </install/prefix> ~~~ + PYTHONPATH=/home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages + PYTHONDONTWRITEBYTECODE=1 + /usr/bin/pytest -ra =========================================================================== test session starts ============================================================================ platform linux -- Python 3.8.9, pytest-6.2.4, py-1.10.0, pluggy-0.13.1 benchmark: 3.4.1 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.000005 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=100000) Using --randomly-seed=2664516846 rootdir: /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1 plugins: forked-1.3.0, shutil-1.7.0, virtualenv-1.7.0, expect-1.1.0, httpbin-1.0.0, flake8-1.0.7, timeout-1.4.2, betamax-0.8.1, freezegun-0.4.2, case-1.5.3, isort-1.3.0, aspectlib-1.5.2, asyncio-0.15.1, toolbox-0.5, xprocess-0.17.1, aiohttp-0.3.0, checkdocs-2.7.0, mock-3.6.1, rerunfailures-9.1.1, requests-mock-1.9.3, cov-2.12.1, pyfakefs-4.5.0, cases-3.6.1, flaky-3.7.0, hypothesis-6.14.0, benchmark-3.4.1, xdist-2.3.0, pylama-7.7.1, randomly-3.8.0, Faker-8.8.2, datadir-1.3.1, regressions-2.2.0 collected 240 items test/test_statemachine.py ................. [ 7%] test/test_functional.py E [ 7%] test/test_dependencies.py ..... [ 9%] test/test_parsers/test_get_parser_class.py ... [ 10%] test/test_writers/test_latex2e_misc.py . [ 11%] test/test_publisher.py .... [ 12%] test/test_writers/test_get_writer_class.py ... [ 14%] test/test__init__.py .. [ 15%] . . [ 15%] test/test__init__.py ...... [ 17%] test/test_settings.py ........................ [ 28%] test/test_writers/test_docutils_xml.py ..... [ 30%] test/test_parsers/test_parser.py . [ 30%] test/test_transforms/test___init__.py . [ 30%] test/test_language.py EEEE [ 32%] test/test_traversals.py . [ 33%] test/test_writers/test_odt.py .......... [ 37%] test/test_command_line.py F [ 37%] test/test_writers/test_html5_polyglot_parts.py EE [ 38%] test/test_nodes.py ............................... [ 51%] test/test_writers/test_html5_polyglot_misc.py ............... [ 57%] test/test_pickle.py . [ 58%] tools/test/test_buildhtml.py .. [ 58%] test/test_io.py ................. [ 66%] test/test_readers/test_get_reader_class.py ... [ 67%] test/test_error_reporting.py ............. [ 72%] test/test_writers/test_html4css1_misc.py ............... [ 79%] test/test_parsers/test_rst/test_directives/test_code_parsing.py .. [ 79%] test/test_utils.py ........................ [ 89%] test/test_parsers/test_recommonmark/test_misc.py ..Fs [ 91%] test/test_parsers/test_rst/test_directives/test__init__.py .... [ 93%] test/test_viewlist.py ................ [100%] ================================================================================== ERRORS ================================================================================== ________________________________________________________________ ERROR at setup of FunctionalTestCase.test _________________________________________________________________ self = <[AttributeError("'FunctionalTestCase' object has no attribute '_testMethodName'") raised in repr()] FunctionalTestCase object at 0x7fbd75666df0>, args = ('test',) kwargs = {} def __init__(self, *args, **kwargs): """Set self.configfile, pass arguments to parent __init__.""" > self.configfile = kwargs['configfile'] E KeyError: 'configfile' /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_functional.py:95: KeyError ____________________________________________________________ ERROR at setup of LanguageTestCase.test_directives ____________________________________________________________ self = <[AttributeError("'LanguageTestCase' object has no attribute '_testMethodName'") raised in repr()] LanguageTestCase object at 0x7fbd754ce0d0> args = ('test_directives',), kwargs = {} def __init__(self, *args, **kwargs): self.ref = docutils.languages.get_language(reference_language, _reporter) > self.language = kwargs['language'] E KeyError: 'language' /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_language.py:81: KeyError ______________________________________________________________ ERROR at setup of LanguageTestCase.test_roles _______________________________________________________________ self = <[AttributeError("'LanguageTestCase' object has no attribute '_testMethodName'") raised in repr()] LanguageTestCase object at 0x7fbd753f98b0>, args = ('test_roles',) kwargs = {} def __init__(self, *args, **kwargs): self.ref = docutils.languages.get_language(reference_language, _reporter) > self.language = kwargs['language'] E KeyError: 'language' /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_language.py:81: KeyError _______________________________________________________ ERROR at setup of LanguageTestCase.test_bibliographic_fields _______________________________________________________ self = <[AttributeError("'LanguageTestCase' object has no attribute '_testMethodName'") raised in repr()] LanguageTestCase object at 0x7fbd753c4850> args = ('test_bibliographic_fields',), kwargs = {} def __init__(self, *args, **kwargs): self.ref = docutils.languages.get_language(reference_language, _reporter) > self.language = kwargs['language'] E KeyError: 'language' /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_language.py:81: KeyError ______________________________________________________________ ERROR at setup of LanguageTestCase.test_labels ______________________________________________________________ self = <[AttributeError("'LanguageTestCase' object has no attribute '_testMethodName'") raised in repr()] LanguageTestCase object at 0x7fbd754181f0> args = ('test_labels',), kwargs = {} def __init__(self, *args, **kwargs): self.ref = docutils.languages.get_language(reference_language, _reporter) > self.language = kwargs['language'] E KeyError: 'language' /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_language.py:81: KeyError ______________________________________________________ ERROR at setup of HtmlWriterPublishPartsTestCase.test_publish _______________________________________________________ self = <[AttributeError("'HtmlWriterPublishPartsTestCase' object has no attribute '_testMethodName'") raised in repr()] HtmlWriterPublishPartsTestCase object at 0x7fbd54e7e550> args = ('test_publish',), kwargs = {} def __init__(self, *args, **kwargs): if 'writer_name' in kwargs: self.writer_name = kwargs['writer_name'] del kwargs['writer_name'] > CustomTestCase.__init__(self, *args, **kwargs) E TypeError: __init__() missing 3 required positional arguments: 'input', 'expected', and 'id' /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/DocutilsTestSupport.py:673: TypeError ______________________________________________________ ERROR at setup of Html5WriterPublishPartsTestCase.test_publish ______________________________________________________ self = <[AttributeError("'Html5WriterPublishPartsTestCase' object has no attribute '_testMethodName'") raised in repr()] Html5WriterPublishPartsTestCase object at 0x7fbd75348160> args = ('test_publish',), kwargs = {} def __init__(self, *args, **kwargs): if 'writer_name' in kwargs: self.writer_name = kwargs['writer_name'] del kwargs['writer_name'] > CustomTestCase.__init__(self, *args, **kwargs) E TypeError: __init__() missing 3 required positional arguments: 'input', 'expected', and 'id' /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/DocutilsTestSupport.py:673: TypeError ================================================================================= FAILURES ================================================================================= _____________________________________________________________ CommandLineEncodingTests.test_sys_argv_decoding ______________________________________________________________ self = <docutils.frontend.OptionParser object at 0x7fbd54bba550>, args = ['-ra', '--source-url=test.txt', '--title=Dornröschen'] values = <Values at 0x7fbd54bba2e0: {'title': None, 'generator': True, 'datestamp': "%Y-%m-%d %H:%M UTC (If you see this in tes..._visitor': None, '_disable_config': None, '_source': None, '_destination': None, '_config_files': ['./docutils.conf']}> def parse_args(self, args=None, values=None): """ parse_args(args : [string] = sys.argv[1:], values : Values = None) -> (values : Values, args : [string]) Parse the command-line options found in 'args' (default: sys.argv[1:]). Any errors result in a call to 'error()', which by default prints the usage message to stderr and calls sys.exit() with an error message. On success returns a pair (values, args) where 'values' is a Values instance (with all your option values) and 'args' is the list of arguments left over after parsing options. """ rargs = self._get_args(args) if values is None: values = self.get_default_values() # Store the halves of the argument list as attributes for the # convenience of callbacks: # rargs # the rest of the command-line (the "r" stands for # "remaining" or "right-hand") # largs # the leftover arguments -- ie. what's left after removing # options and their arguments (the "l" stands for "leftover" # or "left-hand") self.rargs = rargs self.largs = largs = [] self.values = values try: > stop = self._process_args(largs, rargs, values) /usr/lib64/python3.8/optparse.py:1387: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <docutils.frontend.OptionParser object at 0x7fbd54bba550>, largs = [], rargs = ['--source-url=test.txt', '--title=Dornröschen'] values = <Values at 0x7fbd54bba2e0: {'title': None, 'generator': True, 'datestamp': "%Y-%m-%d %H:%M UTC (If you see this in tes..._visitor': None, '_disable_config': None, '_source': None, '_destination': None, '_config_files': ['./docutils.conf']}> def _process_args(self, largs, rargs, values): """_process_args(largs : [string], rargs : [string], values : Values) Process command-line arguments and populate 'values', consuming options and arguments from 'rargs'. If 'allow_interspersed_args' is false, stop at the first non-option argument. If true, accumulate any interspersed non-option arguments in 'largs'. """ while rargs: arg = rargs[0] # We handle bare "--" explicitly, and bare "-" is handled by the # standard arg handler since the short arg case ensures that the # len of the opt string is greater than 1. if arg == "--": del rargs[0] return elif arg[0:2] == "--": # process a single long option (possibly with value(s)) self._process_long_opt(rargs, values) elif arg[:1] == "-" and len(arg) > 1: # process a cluster of short options (possibly with # value(s) for the last one only) > self._process_short_opts(rargs, values) /usr/lib64/python3.8/optparse.py:1431: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <docutils.frontend.OptionParser object at 0x7fbd54bba550>, rargs = ['--source-url=test.txt', '--title=Dornröschen'] values = <Values at 0x7fbd54bba2e0: {'title': None, 'generator': True, 'datestamp': "%Y-%m-%d %H:%M UTC (If you see this in tes..._visitor': None, '_disable_config': None, '_source': None, '_destination': None, '_config_files': ['./docutils.conf']}> def _process_short_opts(self, rargs, values): arg = rargs.pop(0) stop = False i = 1 for ch in arg[1:]: opt = "-" + ch option = self._short_opt.get(opt) i += 1 # we have consumed a character if not option: raise BadOptionError(opt) if option.takes_value(): # Any characters left in arg? Pretend they're the # next arg, and stop consuming characters of arg. if i < len(arg): rargs.insert(0, arg[i:]) stop = True nargs = option.nargs if len(rargs) < nargs: self.error(ngettext( "%(option)s option requires %(number)d argument", "%(option)s option requires %(number)d arguments", nargs) % {"option": opt, "number": nargs}) elif nargs == 1: value = rargs.pop(0) else: value = tuple(rargs[0:nargs]) del rargs[0:nargs] else: # option doesn't take a value value = None > option.process(opt, value, values, self) /usr/lib64/python3.8/optparse.py:1536: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Option at 0x7fbd54edfd90: -r/--report>, opt = '-r', value = 'a' values = <Values at 0x7fbd54bba2e0: {'title': None, 'generator': True, 'datestamp': "%Y-%m-%d %H:%M UTC (If you see this in tes..._visitor': None, '_disable_config': None, '_source': None, '_destination': None, '_config_files': ['./docutils.conf']}> parser = <docutils.frontend.OptionParser object at 0x7fbd54bba550> def process(self, opt, value, values, parser): """ Call the validator function on applicable settings and evaluate the 'overrides' option. Extends `optparse.Option.process`. """ > result = optparse.Option.process(self, opt, value, values, parser) /home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/frontend.py:354: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Option at 0x7fbd54edfd90: -r/--report>, opt = '-r', value = 'a' values = <Values at 0x7fbd54bba2e0: {'title': None, 'generator': True, 'datestamp': "%Y-%m-%d %H:%M UTC (If you see this in tes..._visitor': None, '_disable_config': None, '_source': None, '_destination': None, '_config_files': ['./docutils.conf']}> parser = <docutils.frontend.OptionParser object at 0x7fbd54bba550> def process(self, opt, value, values, parser): # First, convert the value(s) to the right type. Howl if any # value(s) are bogus. > value = self.convert_value(opt, value) /usr/lib64/python3.8/optparse.py:779: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Option at 0x7fbd54edfd90: -r/--report>, opt = '-r', value = 'a' def convert_value(self, opt, value): if value is not None: if self.nargs == 1: > return self.check_value(opt, value) /usr/lib64/python3.8/optparse.py:771: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Option at 0x7fbd54edfd90: -r/--report>, opt = '-r', value = 'a' def check_value(self, opt, value): checker = self.TYPE_CHECKER.get(self.type) if checker is None: return value else: > return checker(self, opt, value) /usr/lib64/python3.8/optparse.py:766: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ option = <Option at 0x7fbd54edfd90: -r/--report>, opt = '-r', value = 'a' def check_choice(option, opt, value): if value in option.choices: return value else: choices = ", ".join(map(repr, option.choices)) > raise OptionValueError( _("option %s: invalid choice: %r (choose from %s)") % (opt, value, choices)) E optparse.OptionValueError: option -r: invalid choice: 'a' (choose from 'info', '1', 'warning', '2', 'error', '3', 'severe', '4', 'none', '5') /usr/lib64/python3.8/optparse.py:440: OptionValueError During handling of the above exception, another exception occurred: self = <test_command_line.CommandLineEncodingTests testMethod=test_sys_argv_decoding> def test_sys_argv_decoding(self): if argv_encoding == 'ascii': # cannot test return sys.argv.append('--source-url=test.txt') # pure ASCII argument if sys.version_info < (3, 0): sys.argv.append(u'--title=Dornröschen'.encode(argv_encoding)) else: sys.argv.append(u'--title=Dornröschen') publisher = docutils.core.Publisher() > publisher.process_command_line() /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_command_line.py:41: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/core.py:162: in process_command_line self.settings = option_parser.parse_args(argv) /usr/lib64/python3.8/optparse.py:1389: in parse_args self.error(str(err)) /usr/lib64/python3.8/optparse.py:1569: in error self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg)) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <docutils.frontend.OptionParser object at 0x7fbd54bba550>, status = 2 msg = "pytest: error: option -r: invalid choice: 'a' (choose from 'info', '1', 'warning', '2', 'error', '3', 'severe', '4', 'none', '5')\n" def exit(self, status=0, msg=None): if msg: sys.stderr.write(msg) > sys.exit(status) E SystemExit: 2 /usr/lib64/python3.8/optparse.py:1559: SystemExit --------------------------------------------------------------------------- Captured stderr call --------------------------------------------------------------------------- Usage ===== pytest [options] pytest: error: option -r: invalid choice: 'a' (choose from 'info', '1', 'warning', '2', 'error', '3', 'severe', '4', 'none', '5') ________________________________________________________________ reCommonMarkParserTests.test_parsing_error ________________________________________________________________ self = <test_parsers.test_recommonmark.test_misc.reCommonMarkParserTests testMethod=test_parsing_error> @unittest.skipUnless(recommonmark_wrapper.CommonMarkParser, skip_msg) def test_parsing_error(self): > output = publish_string(sample1, parser_name='recommonmark', settings_overrides={'warning_stream': ''}) /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_parsers/test_recommonmark/test_misc.py:55: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/core.py:407: in publish_string output, pub = publish_programmatically( /home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/core.py:665: in publish_programmatically output = pub.publish(enable_exit_status=enable_exit_status) /home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/core.py:217: in publish self.document = self.reader.read(self.source, self.parser, /home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/readers/__init__.py:72: in read self.parse() /home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/readers/__init__.py:78: in parse self.parser.parse(self.input, document) /home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/parsers/recommonmark_wrapper.py:117: in parse if node['level'] != section_level: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <section "title": <title...><paragraph...>>, key = 'level' def __getitem__(self, key): if isinstance(key, basestring): > return self.attributes[key] E KeyError: 'level' /home/tkloczko/rpmbuild/BUILDROOT/python-docutils-0.17.1-2.fc35.x86_64/usr/lib/python3.8/site-packages/docutils/nodes.py:652: KeyError ============================================================================= warnings summary ============================================================================= test/test_parsers/test_recommonmark/test_section_headers.py:37 /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_parsers/test_recommonmark/test_section_headers.py:37: DeprecationWarning: invalid escape sequence \ """\ test/test_parsers/test_recommonmark/test_section_headers.py:50 /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_parsers/test_recommonmark/test_section_headers.py:50: DeprecationWarning: invalid escape sequence \ """\ test/test_parsers/test_recommonmark/test_section_headers.py:164 /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_parsers/test_recommonmark/test_section_headers.py:164: DeprecationWarning: invalid escape sequence \ """\ test/test_transforms/test___init__.py:20 /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/test_transforms/test___init__.py:20: PytestCollectionWarning: cannot collect test class 'TestTransform' because it has a __init__ constructor (from: test/test_transforms/test___init__.py) class TestTransform(transforms.Transform): test/test_settings.py::ConfigFileTests::test_old test/test_settings.py::ConfigFileTests::test_old_and_new test/test_settings.py::ConfigEnvVarFileTests::test_old_and_new test/test_settings.py::ConfigEnvVarFileTests::test_old /home/tkloczko/rpmbuild/BUILD/docutils-0.17.1/test/data/config_old.txt:0: ConfigDeprecationWarning: The "[option]" section is deprecated. Support for old-format configuration files may be removed in a future Docutils release. Please revise your configuration files. See <http://docutils.sf.net/docs/user/config.html>, section "Old-Format Configuration Files". test/test_parsers/test_recommonmark/test_misc.py::reCommonMarkParserTests::test_raw_disabled_inline test/test_parsers/test_recommonmark/test_misc.py::reCommonMarkParserTests::test_raw_disabled test/test_parsers/test_recommonmark/test_misc.py::reCommonMarkParserTests::test_parsing_error /usr/lib/python3.8/site-packages/recommonmark/parser.py:75: UserWarning: Container node skipped: type=document warn("Container node skipped: type={0}".format(mdnode.t)) -- Docs: https://docs.pytest.org/en/stable/warnings.html ========================================================================= short test summary info ========================================================================== SKIPPED [1] test/test_parsers/test_recommonmark/test_misc.py:91: recommonmark_wrapper: parser found, fallback not used ERROR test/test_functional.py::FunctionalTestCase::test - KeyError: 'configfile' ERROR test/test_language.py::LanguageTestCase::test_directives - KeyError: 'language' ERROR test/test_language.py::LanguageTestCase::test_roles - KeyError: 'language' ERROR test/test_language.py::LanguageTestCase::test_bibliographic_fields - KeyError: 'language' ERROR test/test_language.py::LanguageTestCase::test_labels - KeyError: 'language' ERROR test/test_writers/test_html5_polyglot_parts.py::HtmlWriterPublishPartsTestCase::test_publish - TypeError: __init__() missing 3 required positional arguments: 'inpu... ERROR test/test_writers/test_html5_polyglot_parts.py::Html5WriterPublishPartsTestCase::test_publish - TypeError: __init__() missing 3 required positional arguments: 'inp... FAILED test/test_command_line.py::CommandLineEncodingTests::test_sys_argv_decoding - SystemExit: 2 FAILED test/test_parsers/test_recommonmark/test_misc.py::reCommonMarkParserTests::test_parsing_error - KeyError: 'level' ===================================================== 2 failed, 229 passed, 1 skipped, 11 warnings, 7 errors in 10.64s ===================================================== ~~~ --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Günter M. <mi...@us...> - 2022-01-04 23:34:18
|
Currently, "setuptools" is also used for [editable installs](https://docutils.sourceforge.io/docs/dev/repository.html#editable-installs). Will (editable) installs also work without `setup.py` when using pip 20.3.4 (the version in current Debian/stable) ? --- ** [patches:#186] Modernise packaging** **Status:** open **Group:** None **Created:** Fri Dec 31, 2021 03:16 AM UTC by Adam Turner **Last Updated:** Tue Jan 04, 2022 03:12 AM UTC **Owner:** nobody **Attachments:** - [0001-Use-flit-and-pyproject.toml.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0001-Use-flit-and-pyproject.toml.patch) (12.2 kB; application/octet-stream) - [0002-Use-entry-points.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0002-Use-entry-points.patch) (20.7 kB; application/octet-stream) - [0003-update-docs-etc-after-packaging-changes.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0003-update-docs-etc-after-packaging-changes.patch) (49.3 kB; application/octet-stream) Hi, I had a go at modernising the packaging stack. `setup.py` based invocations have been deprecated (https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html), and setuptools may remove them in the future. This takes the opportunity to move to a PEP 621 based declarative config, and also fixes a longstanding TODO item about providing script wappers for the frontend tools on windows, by migrating them to entry points. I've updated install and development docs with the new guidance, and updated references to the frontend tools to remove `.py`, given they are now installed as proper scripts. Hope this is appreciated -- happy to make revisions etc to help getting this merged. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Günter M. <mi...@us...> - 2022-01-04 21:43:05
|
On 2022-01-04, Adam Turner via Docutils-develop wrote: > Most usage of Docutils today is programmatic, and not via the command > line tools ... It should not come as a surprise that projects on PyPi prefer programmatic use over command line tools. OTOH, we will not easily find out how many end-users and non-Python projects use the front-end tools in a Makefile or custom script to generate documentation in HTML, PDF, or trof (man page) formats and will be affected by a name change. As a recent addition, `docutils-cli.py` may less used and hence a change there may cause less disruption. Maybe adding a `docutils-cli` or `docutils` "entry point" for the benefit of Windows users could become a separate feature request. --- ** [patches:#186] Modernise packaging** **Status:** open **Group:** None **Created:** Fri Dec 31, 2021 03:16 AM UTC by Adam Turner **Last Updated:** Tue Jan 04, 2022 03:12 AM UTC **Owner:** nobody **Attachments:** - [0001-Use-flit-and-pyproject.toml.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0001-Use-flit-and-pyproject.toml.patch) (12.2 kB; application/octet-stream) - [0002-Use-entry-points.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0002-Use-entry-points.patch) (20.7 kB; application/octet-stream) - [0003-update-docs-etc-after-packaging-changes.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0003-update-docs-etc-after-packaging-changes.patch) (49.3 kB; application/octet-stream) Hi, I had a go at modernising the packaging stack. `setup.py` based invocations have been deprecated (https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html), and setuptools may remove them in the future. This takes the opportunity to move to a PEP 621 based declarative config, and also fixes a longstanding TODO item about providing script wappers for the frontend tools on windows, by migrating them to entry points. I've updated install and development docs with the new guidance, and updated references to the frontend tools to remove `.py`, given they are now installed as proper scripts. Hope this is appreciated -- happy to make revisions etc to help getting this merged. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Günter M. <mi...@us...> - 2022-01-04 20:20:05
|
On 2022-01-04, Adam Turner via Docutils-develop wrote: > ... I don't believe installing Docutils from source using just the > standard library will be possible for much longer What I have in mind is a "manual install" (point 3 in https://docutils.sourceforge.io/docs/dev/repository.html#editable-installs). You may also call it "using Docutils without installing". This can be done without any dependencies and offers most flexibility (e.g. select which front-ends to make available as commands and under which name). --- ** [patches:#186] Modernise packaging** **Status:** open **Group:** None **Created:** Fri Dec 31, 2021 03:16 AM UTC by Adam Turner **Last Updated:** Tue Jan 04, 2022 03:12 AM UTC **Owner:** nobody **Attachments:** - [0001-Use-flit-and-pyproject.toml.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0001-Use-flit-and-pyproject.toml.patch) (12.2 kB; application/octet-stream) - [0002-Use-entry-points.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0002-Use-entry-points.patch) (20.7 kB; application/octet-stream) - [0003-update-docs-etc-after-packaging-changes.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0003-update-docs-etc-after-packaging-changes.patch) (49.3 kB; application/octet-stream) Hi, I had a go at modernising the packaging stack. `setup.py` based invocations have been deprecated (https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html), and setuptools may remove them in the future. This takes the opportunity to move to a PEP 621 based declarative config, and also fixes a longstanding TODO item about providing script wappers for the frontend tools on windows, by migrating them to entry points. I've updated install and development docs with the new guidance, and updated references to the frontend tools to remove `.py`, given they are now installed as proper scripts. Hope this is appreciated -- happy to make revisions etc to help getting this merged. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Günter M. <mi...@us...> - 2022-01-04 10:33:48
|
I see your point. OTOH, I don't think there is wide use (given the problems of this approach with, e.g. output for mobile phones or considering the difference in line lenght when using proportinal fonts vs. monospace). So, Docutils will not provide this feature "out of the box" anytime soon but we are ready to help with a custom solution. --- ** [feature-requests:#85] Enable easily-typed hard line-breaks in paragraphs.** **Status:** open **Group:** Default **Labels:** linebreaks **Created:** Sat Jan 01, 2022 08:21 AM UTC by jon **Last Updated:** Tue Jan 04, 2022 10:13 AM UTC **Owner:** nobody During the last few weeks I've spent some time carefully studying reStructuredText and Python-Markdown. I would prefer to write with reStructuredText, but Markdown has one feature that is lacking in reST: easy-to-type line-breaks in paragraphs. I'm addicted to semantic line breaking. I think in medium-length phrases that can fit in one line. Probably this was heightened by working with video subtitles, but I've always felt that prose can be understood more quickly if the line-breaks fall between semantic units. Even when I can't make semantic units fit neatly, I still like to control where the lines break. An extension for Python-Markdown, nl2br, completely disables markdown's removal of line-breaks, so I can simply write the way I usually do. With another markdown extension, you type a backslash to indicate that you want to keep the following line-break. I'm aware of the methods available in reST: starting every line of a block with `| `, or typing something like `|br|` at the end of a line. They're not really suitable to use with every line of every paragraph. Perhaps the removal of line-breaks from paragraphs is baked so deeply into reST that it's not practical to change the current behaviour? Anyway, my question/feature-request is: can you make either or both of the following methods available to users? 1. Preferably, set a document-wide parameter that causes actual line-breaks in paragraphs to be kept. 2. If that's not practical, create a hard line-break by typing a backslash immediately before a line-break (with or without a space before the backslash). I'd like to convert my reST docs to html5, using `<br>\n` for line breaks. I don't understand why arbitrary line-breaks are the norm. In early email and code editors line length was limited, but I don't see why any form of markup or markdown expects people to insert them these days. When I don't want semantic breaks, I simply don't insert any breaks at all, and then a paragraph is a single unbroken line that gets wrapped at the margins. Why isn't *this* the norm? Hope my point of view makes at least a little sense to you. --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Günter M. <mi...@us...> - 2022-01-04 10:13:42
|
Not providing for "hard line break elements" in the Docutils document model and reStructuredText syntax was a deliberate decision at the time these two were devised. The original idea of preserving all source line breaks in HTML display can be implemented with the current document model with a custom HTML writer. However, times have changed and there are new arguments and use-cases for hard line breaks. Something like a `<br>` inline node or special handling of `<inline class=line-break>` [inline](https://docutils.sourceforge.io/docs/ref/doctree.html#inline) nodes may be considered. The latter would not change the document model and could be implemented at the writer level or via stylesheet rules. Whether to add a reStructuredText syntax for hard line breaks can be decided independently. The current rules require a non-white character in a role defined with `.. role:: line-break`. I would like to hear David Goodger on this before any decision. --- ** [feature-requests:#85] Enable easily-typed hard line-breaks in paragraphs.** **Status:** open **Group:** Default **Labels:** linebreaks **Created:** Sat Jan 01, 2022 08:21 AM UTC by jon **Last Updated:** Mon Jan 03, 2022 01:16 PM UTC **Owner:** nobody During the last few weeks I've spent some time carefully studying reStructuredText and Python-Markdown. I would prefer to write with reStructuredText, but Markdown has one feature that is lacking in reST: easy-to-type line-breaks in paragraphs. I'm addicted to semantic line breaking. I think in medium-length phrases that can fit in one line. Probably this was heightened by working with video subtitles, but I've always felt that prose can be understood more quickly if the line-breaks fall between semantic units. Even when I can't make semantic units fit neatly, I still like to control where the lines break. An extension for Python-Markdown, nl2br, completely disables markdown's removal of line-breaks, so I can simply write the way I usually do. With another markdown extension, you type a backslash to indicate that you want to keep the following line-break. I'm aware of the methods available in reST: starting every line of a block with `| `, or typing something like `|br|` at the end of a line. They're not really suitable to use with every line of every paragraph. Perhaps the removal of line-breaks from paragraphs is baked so deeply into reST that it's not practical to change the current behaviour? Anyway, my question/feature-request is: can you make either or both of the following methods available to users? 1. Preferably, set a document-wide parameter that causes actual line-breaks in paragraphs to be kept. 2. If that's not practical, create a hard line-break by typing a backslash immediately before a line-break (with or without a space before the backslash). I'd like to convert my reST docs to html5, using `<br>\n` for line breaks. I don't understand why arbitrary line-breaks are the norm. In early email and code editors line length was limited, but I don't see why any form of markup or markdown expects people to insert them these days. When I don't want semantic breaks, I simply don't insert any breaks at all, and then a paragraph is a single unbroken line that gets wrapped at the margins. Why isn't *this* the norm? Hope my point of view makes at least a little sense to you. --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Adam T. <aa-...@us...> - 2022-01-04 03:12:14
|
>Installation should be possible without dependencies other than stock Python and its standard library. There's an intention in python packaging to become more standards based (PEPs 517, 518, 621, 660, etc) and less reliant on a single blessed tool (setuptools). There have been recent discussions of removing setuptools from the default python binaries (https://mail.python.org/archives/list/pyt...@py.../thread/3BVAUIQOEOXAULHVYQNLLQIZQQETX2EV/) -- the only constraint seems to be when `pip` no longer needs it. My argument in short is that I don't believe installing Docutils from source using just the standard library will be possible for much longer -- `disutils` is being removed from the stdlib & will be removed in Python 3.12, and after that there are no bundled building mechanisms. Flit (the system I proposed) has a strong focus / emphasis on boostraping -- see https://flit.readthedocs.io/en/latest/bootstrap.html. If you have the sources of flit and Docutils, you can end up with a functioning installation of Docutils using only the standard library -- would that be good enough reassurance? > Renaming setup.py to pyproject.toml before applying the changes to make it a toml file would allow keeping the classifiers in the version history. Will do > I wonder if we could eat the cake and have it by moving the tools/ directory I sort of did this in `_cli.py` -- see the section that starts `DEPRECATED ENTRY POINTS`. I switched from using the `publish_command_line` functions to routing through `docutils-cli` as it shows how they're all connected. If you wanted to keep the `.py` files in the tools directory then we could add aliases -- the contents of `rst2html5.py` would simply be: ```python from docutils import _cli _cli.publish_html5() ``` > templates for custom, home made front-ends We could also add explicit templates in an `examples` folder or similar -- this would allow demonstrating potential usages of the API without needing to use it ourselves. >A name change for the frontend tools is an API change that requires an advance warning in the RELEASE-NOTES Of course, I can prepare a patch that only updates `RELEASE-NOTES` > If implemented via an "entry point", the command name docutils-cli may also be simplified to docutils. OK, will do. We can also keep the legacy `docutils-cli` as an alias and emit deprecation warnings until removal in the next major version. > Once we are at it, it may be worth discussing which front-end tools should be provided. The generic docutils-cli could obsolete some or all of the rst2*.py scripts, but it is new and not yet reviewed/endorsed by Docutils main author David Goodger. > Also, regular Docutils users and developers benefit from dedicated tools (and TAB-expansion after typing rst2) while users installing Docutils only because it is required by some other package may prefer less "noise" in the binary path. (note the below is entirely personal opinions, I am not David!) I think a single front-end tool significantly simplifies a lot of things -- the `docutils-cli` wrapper is not complex, which gives it significant points in favour in my book. Most usage of Docutils today is programmatic, and not via the command line tools (see the table at the bottom of this post - it shows all the projects that have a full dependency on Docutils with over 500k downloads in the last month. Of those 8, none use the command line tools) A converstation I wanted to have at a later date is starting to separate the application and library usages of Docutils (whilst keeping full backwards compatability). Having a single front-end command line interface would make that (theoretical) work significantly easier. I also suspect (although the data does not exist) that most command line uses of the Docutils tools will be `rst2html(5)`. This is already the default in `docutils-cli`, so it is a drop-in replacement. My suggested timeline is: - 0.19.0: announce upcoming changes. Just the drop of support of `<3.7` may be big enough to release 0.19 -- if so could the future changes notice be included before you release it please? - 0.20.0: add entrypoints, retain `rst2*` files in `tools/` (although no longer automatically copied into PATH), deprecate `rst2*` and `docutils-cli` commands at runtime (the deprecation message contains the replacement invocation needed) - 0.21.0: Remove the deprecated `rst2*` and `docutils-cli` aliases, leaving the single `docutils` command line tool. I'd be interested in your thoughts on the proposed timeline -- is it workable? Is there anything I missed? (it is quite late here!) A ------ package name | downloads | pin | type ------------ | --------- | --- | ---- awscli | 105,842,835 | >=0.10,<0.16 | pure docutils apache-airflow | 4,023,459 | <0.17 | with Sphinx sphinx | 3,843,715 | <0.18,>=0.14 | with Sphinx readme-renderer | 2,353,477 | >=0.13.1 | pure docutils sphinx-rtd-theme | 1,740,846 | <0.18 | with Sphinx c7n | 945,488 | ==0.17.1 | with Sphinx c7n-org | 837,789 | ==0.17.1 | with Sphinx recommonmark | 611,332 | >=0.11 | with Sphinx --- ** [patches:#186] Modernise packaging** **Status:** open **Group:** None **Created:** Fri Dec 31, 2021 03:16 AM UTC by Adam Turner **Last Updated:** Mon Jan 03, 2022 08:30 PM UTC **Owner:** nobody **Attachments:** - [0001-Use-flit-and-pyproject.toml.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0001-Use-flit-and-pyproject.toml.patch) (12.2 kB; application/octet-stream) - [0002-Use-entry-points.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0002-Use-entry-points.patch) (20.7 kB; application/octet-stream) - [0003-update-docs-etc-after-packaging-changes.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0003-update-docs-etc-after-packaging-changes.patch) (49.3 kB; application/octet-stream) Hi, I had a go at modernising the packaging stack. `setup.py` based invocations have been deprecated (https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html), and setuptools may remove them in the future. This takes the opportunity to move to a PEP 621 based declarative config, and also fixes a longstanding TODO item about providing script wappers for the frontend tools on windows, by migrating them to entry points. I've updated install and development docs with the new guidance, and updated references to the frontend tools to remove `.py`, given they are now installed as proper scripts. Hope this is appreciated -- happy to make revisions etc to help getting this merged. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Adam T. <aa-...@us...> - 2022-01-04 01:54:05
|
@milde I've updated the implementation, please see https://github.com/AA-Turner/docutils/pull/2.patch // https://github.com/AA-Turner/docutils/pull/2 > here is no need to translate the short alias 'bcp' OK, dropped > Why do you raise SystemExit I can't remember, but I agree with you. Dropped this. > How about the following ... I think I'd prefer keeping the change smaller for now -- one thing I did do in the most recent update is create a factory function `rfc_like_role`, so there is the option to extend Docutils to add custom things should people need it. A --- ** [feature-requests:#61] Support for :BCP: role, similar** **Status:** open **Group:** Default **Created:** Tue Apr 09, 2019 08:46 AM UTC by Roberto Polli **Last Updated:** Mon Jan 03, 2022 03:43 PM UTC **Owner:** nobody ## I wish - support for referencing IETF Best Current Practices, eg: :BCP:`47`role - the processing is similar to :RFC: ## Notes - sphinx people suggests that goes in docutils. see https://github.com/sphinx-doc/sphinx/issues/6255 --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Günter M. <mi...@us...> - 2022-01-03 20:30:10
|
Thank you for the elaborated patch set. Please be patient with our hesitation to apply it as-is. Although officially still in Beta stage (version number <1.0), Docutils is widely used as if it were stable and we try to minimise the impact of changes on users. Installation should be possible without dependencies other than stock Python and its standard library. There is an exception with setup.py requiring "setuptools", but currently it's also possible to get Docutils running by placing a `*.pth` file in the Python path and symlinks for the front-ends in the binary path (`/usr/local/bin/rst2html5 -> /usr/local/src/Docutils/docutils/tools/rst2html5.py`, say). Switching to static metadata should be possible without violating this condition. Renaming setup.py to pyproject.toml before applying the changes to make it a `toml` file would allow keeping the classifiers in the version history. The "longstanding TODO item about providing script wappers for the frontend tools on windows, by migrating them to entry points" comes as a suprise to me. I see the potential benefit for Windows users, OTOH, I'd like to keep the front-ends as executable files for "hand installation" as well as templates for custom, home made front-ends. I wonder if we could eat the cake and have it by moving the `tools/` directory inside the package (maybe renaming it to `cli/`) and modifying the front-end tools to provide an entry function that is executed `if name == '__main__`. A name change for the frontend tools is an API change that requires an advance warning in the RELEASE-NOTES (note that, e.g., Debian already drops the `*.py` extension from the front-end tools). If implemented via an "entry point", the command name `docutils-cli` may also be simplified to `docutils`. Once we are at it, it may be worth discussing which front-end tools should be provided. The generic `docutils-cli` could obsolete some or all of the `rst2*.py` scripts, but it is new and not yet reviewed/endorsed by Docutils main author David Goodger. Also, regular Docutils users and developers benefit from dedicated tools (and TAB-expansion after typing `rst2`) while users installing Docutils only because it is required by some other package may prefer less "noise" in the binary path. --- ** [patches:#186] Modernise packaging** **Status:** open **Group:** None **Created:** Fri Dec 31, 2021 03:16 AM UTC by Adam Turner **Last Updated:** Mon Jan 03, 2022 03:50 AM UTC **Owner:** nobody **Attachments:** - [0001-Use-flit-and-pyproject.toml.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0001-Use-flit-and-pyproject.toml.patch) (12.2 kB; application/octet-stream) - [0002-Use-entry-points.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0002-Use-entry-points.patch) (20.7 kB; application/octet-stream) - [0003-update-docs-etc-after-packaging-changes.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0003-update-docs-etc-after-packaging-changes.patch) (49.3 kB; application/octet-stream) Hi, I had a go at modernising the packaging stack. `setup.py` based invocations have been deprecated (https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html), and setuptools may remove them in the future. This takes the opportunity to move to a PEP 621 based declarative config, and also fixes a longstanding TODO item about providing script wappers for the frontend tools on windows, by migrating them to entry points. I've updated install and development docs with the new guidance, and updated references to the frontend tools to remove `.py`, given they are now installed as proper scripts. Hope this is appreciated -- happy to make revisions etc to help getting this merged. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Günter M. <mi...@us...> - 2022-01-03 15:43:38
|
Thank you for the patch. Any patch that can be applied with `git apply` or `git am -3` is fine. Separate patches for the different commits may be better, you can generate a "commit patch" with `git format-patch` (or via some GUI tools). (Mind that due to SVN limitations, SVN will set the author to the "sponsor" running `git-svn dcommit`.) Small things: There is no need to translate the short alias `'bcp'`. Similar to `'rfc'` and `'pep'` it may be mapped to `'bcp-reference'` or omitted in the language files. (The difference is an info message if converting a foreign language document with `--verbose`). In "docs/ref/rst/roles.txt": changing the anchor to `.. _rfc-role:` allows simpler referencing with `` `RFC role`_``. In test/test_language.py: Why do you raise SystemExit? It is current praxis to let the test suite run on (if possible) and collect all problems. Large question: How about the following (instead or in addition to a new bcp role)? There are many more similar document sets (Debian enhancement proposals or Django enhancement proposals, ..., maybe sometimes also Docutils enhancement proposals), but not all of them are important for everyone. One idea would be to allow deriving custom "RFC-like" roles from "rfc-reference" using the [role](https://docutils.sourceforge.io/docs/ref/rst/directives.html#custom-interpreted-text-roles) directive with the base-URL given as customization option (similar to "language" for roles derived from [code](https://docutils.sourceforge.io/docs/ref/rst/roles.html#code)). A 'bcp' role could then created with ~~~ .. role:: bcp(rfc-reference) :base-url: https://datatracker.ietf.org/doc/html/bcp ~~~ This allows more flexibility. We could also use a placeholder for the actual number. --- ** [feature-requests:#61] Support for :BCP: role, similar** **Status:** open **Group:** Default **Created:** Tue Apr 09, 2019 08:46 AM UTC by Roberto Polli **Last Updated:** Sun Jan 02, 2022 06:59 AM UTC **Owner:** nobody ## I wish - support for referencing IETF Best Current Practices, eg: :BCP:`47`role - the processing is similar to :RFC: ## Notes - sphinx people suggests that goes in docutils. see https://github.com/sphinx-doc/sphinx/issues/6255 --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: jon <j7...@us...> - 2022-01-03 13:16:43
|
This is a long shot, as I've never looked at this code before. In the attached file I've written comments at lines 722 and 738 (search for "# XXX"). I have no idea how to do what I've suggested there, but it looks like it might be the right place to do it. I was playing with rst2html5, and found it easier to look around in its few files rather than in the whole docutils installation. I'm in Australia, so I won't be around for the next 10 hours or so. Attachments: - [rst2html5__init__JH.tar.bz2](https://sourceforge.net/p/docutils/feature-requests/_discuss/thread/0ea5184834/b3df/7270/7347/attachment/rst2html5__init__JH.tar.bz2) (9.3 kB; application/x-bzip) --- ** [feature-requests:#85] Enable easily-typed hard line-breaks in paragraphs.** **Status:** open **Group:** Default **Labels:** linebreaks **Created:** Sat Jan 01, 2022 08:21 AM UTC by jon **Last Updated:** Mon Jan 03, 2022 04:55 AM UTC **Owner:** nobody During the last few weeks I've spent some time carefully studying reStructuredText and Python-Markdown. I would prefer to write with reStructuredText, but Markdown has one feature that is lacking in reST: easy-to-type line-breaks in paragraphs. I'm addicted to semantic line breaking. I think in medium-length phrases that can fit in one line. Probably this was heightened by working with video subtitles, but I've always felt that prose can be understood more quickly if the line-breaks fall between semantic units. Even when I can't make semantic units fit neatly, I still like to control where the lines break. An extension for Python-Markdown, nl2br, completely disables markdown's removal of line-breaks, so I can simply write the way I usually do. With another markdown extension, you type a backslash to indicate that you want to keep the following line-break. I'm aware of the methods available in reST: starting every line of a block with `| `, or typing something like `|br|` at the end of a line. They're not really suitable to use with every line of every paragraph. Perhaps the removal of line-breaks from paragraphs is baked so deeply into reST that it's not practical to change the current behaviour? Anyway, my question/feature-request is: can you make either or both of the following methods available to users? 1. Preferably, set a document-wide parameter that causes actual line-breaks in paragraphs to be kept. 2. If that's not practical, create a hard line-break by typing a backslash immediately before a line-break (with or without a space before the backslash). I'd like to convert my reST docs to html5, using `<br>\n` for line breaks. I don't understand why arbitrary line-breaks are the norm. In early email and code editors line length was limited, but I don't see why any form of markup or markdown expects people to insert them these days. When I don't want semantic breaks, I simply don't insert any breaks at all, and then a paragraph is a single unbroken line that gets wrapped at the margins. Why isn't *this* the norm? Hope my point of view makes at least a little sense to you. --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Günter M. <mi...@us...> - 2022-01-03 12:39:06
|
I.e. we should not use "not annotated" as the only indication of a non-public or provisional part of the API. It would still help in the major task of clearly defining the public API, if we could state that by default: * all functions, classes, and variables are provisional unless annotated * annotated objects that are not part of the public API must say so (either using underscore or in the docstring). * if a module is marked as provisional, this holds for all objects defined in this module, whether they are annotated or not. --- ** [feature-requests:#87] [FR] Giving type annotations to docutils** **Status:** open **Group:** Default **Created:** Mon Jan 03, 2022 03:49 AM UTC by Adam Turner **Last Updated:** Mon Jan 03, 2022 10:18 AM UTC **Owner:** nobody *Sorry for reposting this as a feature request, I couldn't work out how to respond to Günter's post [1] through Sourceforge's web interface* [1]: https://sourceforge.net/p/docutils/mailman/message/37410168/ > > Hi all, > > > I noticed py2 and py36- support will be dropped in the next release. > > Yes, I am currently working on this, ... soon in the repository. Günter @milde -- happy to help with this if you'd like? > > It helps to integrate type annotations in docutils-stub package into > > upstream. > > I believe it helps to develop third-party extensions (including Sphinx). > > Is there any chance to merge it into the docutils? > > In my view, it would make sense to have annotations right in the "master". > > This could also be used as an indicator for the public API: > > In the Docutils Backwards Compatibility Policy, we could change the > clause about the "scope of the public API" to an "opt-in" scheme: only > function/class interfaces with annotations belong to the stable, public > API while not annotated function interfaces may be changed or removed in > future versions if this helps to improve or clean up the code base. > > What do other Docutils developers/contributors/users think? In my experienece, type annotations are often most useful in private / internal code -- the public API is often well specified, and used often enough that you remember the types. Internal methods may be touched less frequently, or the code paths from caller to callee may be less clear, so type hints as a self documenting contract are really useful. I also think that it would be useful to be explicit about the public API in docs/dev/policies.txt -- currently the scope clause links to CPython's backwards compatability rules -- I think that explicit is better than implicit here, in my opinion. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Adam T. <aa-...@us...> - 2022-01-03 10:18:13
|
This is also sort of my problem -- I have many mail aliases (e.g. doc...@ex...) that forward to the single account I send from (ad...@ex...). This allows me to filter incoming emails and if one alias gets on a spam list it isn't a massive deal. That does mean that sending to public mailing lists is an issue though -- why I prefer bug trackers/forums like discourse. If needed though I'll sort myself out eventually! A --- ** [feature-requests:#87] [FR] Giving type annotations to docutils** **Status:** open **Group:** Default **Created:** Mon Jan 03, 2022 03:49 AM UTC by Adam Turner **Last Updated:** Mon Jan 03, 2022 10:13 AM UTC **Owner:** nobody *Sorry for reposting this as a feature request, I couldn't work out how to respond to Günter's post [1] through Sourceforge's web interface* [1]: https://sourceforge.net/p/docutils/mailman/message/37410168/ > > Hi all, > > > I noticed py2 and py36- support will be dropped in the next release. > > Yes, I am currently working on this, ... soon in the repository. Günter @milde -- happy to help with this if you'd like? > > It helps to integrate type annotations in docutils-stub package into > > upstream. > > I believe it helps to develop third-party extensions (including Sphinx). > > Is there any chance to merge it into the docutils? > > In my view, it would make sense to have annotations right in the "master". > > This could also be used as an indicator for the public API: > > In the Docutils Backwards Compatibility Policy, we could change the > clause about the "scope of the public API" to an "opt-in" scheme: only > function/class interfaces with annotations belong to the stable, public > API while not annotated function interfaces may be changed or removed in > future versions if this helps to improve or clean up the code base. > > What do other Docutils developers/contributors/users think? In my experienece, type annotations are often most useful in private / internal code -- the public API is often well specified, and used often enough that you remember the types. Internal methods may be touched less frequently, or the code paths from caller to callee may be less clear, so type hints as a self documenting contract are really useful. I also think that it would be useful to be explicit about the public API in docs/dev/policies.txt -- currently the scope clause links to CPython's backwards compatability rules -- I think that explicit is better than implicit here, in my opinion. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Adam T. <aa-...@us...> - 2022-01-03 10:13:02
|
> That's an interesting take 😬 Aha sorry - imprecision of language strikes again! For almost everyone, type annotations of the public API will be far and away the most useful. For developers of Docutils itself, I believe also annotating private methods will be useful -- my comment was more arguing against just annotating the public API, but carried with it the implicit assumption that the public API would be annotated regardless. Sorry for the misunderstanding! A --- ** [feature-requests:#87] [FR] Giving type annotations to docutils** **Status:** open **Group:** Default **Created:** Mon Jan 03, 2022 03:49 AM UTC by Adam Turner **Last Updated:** Mon Jan 03, 2022 04:05 AM UTC **Owner:** nobody *Sorry for reposting this as a feature request, I couldn't work out how to respond to Günter's post [1] through Sourceforge's web interface* [1]: https://sourceforge.net/p/docutils/mailman/message/37410168/ > > Hi all, > > > I noticed py2 and py36- support will be dropped in the next release. > > Yes, I am currently working on this, ... soon in the repository. Günter @milde -- happy to help with this if you'd like? > > It helps to integrate type annotations in docutils-stub package into > > upstream. > > I believe it helps to develop third-party extensions (including Sphinx). > > Is there any chance to merge it into the docutils? > > In my view, it would make sense to have annotations right in the "master". > > This could also be used as an indicator for the public API: > > In the Docutils Backwards Compatibility Policy, we could change the > clause about the "scope of the public API" to an "opt-in" scheme: only > function/class interfaces with annotations belong to the stable, public > API while not annotated function interfaces may be changed or removed in > future versions if this helps to improve or clean up the code base. > > What do other Docutils developers/contributors/users think? In my experienece, type annotations are often most useful in private / internal code -- the public API is often well specified, and used often enough that you remember the types. Internal methods may be touched less frequently, or the code paths from caller to callee may be less clear, so type hints as a self documenting contract are really useful. I also think that it would be useful to be explicit about the public API in docs/dev/policies.txt -- currently the scope clause links to CPython's backwards compatability rules -- I think that explicit is better than implicit here, in my opinion. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Guenter M. <mi...@us...> - 2022-01-03 09:13:41
|
Dear Takeshi KOMIYA, dear Docutils developers, Adam Turner opened feature request #87 (https://sourceforge.net/p/docutils/feature-requests/87/) for this issue. I suggest moving the discussion there. Thanks, Günter |
|
From: Günter M. <mi...@us...> - 2022-01-03 09:09:09
|
> I couldn't work out how to respond to Günter's post > [1](https://sourceforge.net/p/docutils/mailman/message/37410168/) > through Sourceforge's web interface You may use any e-mail application to send a mail to Doc...@li.... It's explained in the documentation [Docutils Mailing Lists(https://docutils.sourceforge.io/docs/user/mailing-lists.html#docutils-develop) A click on the link given there will open an e-mail application in most browsers. --- ** [feature-requests:#87] [FR] Giving type annotations to docutils** **Status:** open **Group:** Default **Created:** Mon Jan 03, 2022 03:49 AM UTC by Adam Turner **Last Updated:** Mon Jan 03, 2022 04:05 AM UTC **Owner:** nobody *Sorry for reposting this as a feature request, I couldn't work out how to respond to Günter's post [1] through Sourceforge's web interface* [1]: https://sourceforge.net/p/docutils/mailman/message/37410168/ > > Hi all, > > > I noticed py2 and py36- support will be dropped in the next release. > > Yes, I am currently working on this, ... soon in the repository. Günter @milde -- happy to help with this if you'd like? > > It helps to integrate type annotations in docutils-stub package into > > upstream. > > I believe it helps to develop third-party extensions (including Sphinx). > > Is there any chance to merge it into the docutils? > > In my view, it would make sense to have annotations right in the "master". > > This could also be used as an indicator for the public API: > > In the Docutils Backwards Compatibility Policy, we could change the > clause about the "scope of the public API" to an "opt-in" scheme: only > function/class interfaces with annotations belong to the stable, public > API while not annotated function interfaces may be changed or removed in > future versions if this helps to improve or clean up the code base. > > What do other Docutils developers/contributors/users think? In my experienece, type annotations are often most useful in private / internal code -- the public API is often well specified, and used often enough that you remember the types. Internal methods may be touched less frequently, or the code paths from caller to callee may be less clear, so type hints as a self documenting contract are really useful. I also think that it would be useful to be explicit about the public API in docs/dev/policies.txt -- currently the scope clause links to CPython's backwards compatability rules -- I think that explicit is better than implicit here, in my opinion. A --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Günter M. <mi...@us...> - 2022-01-03 08:09:46
|
- **labels**: --> reStructuredText --- ** [feature-requests:#84] Allow optional and repeating arguments in option lists** **Status:** open **Group:** Default **Labels:** reStructuredText **Created:** Mon Nov 01, 2021 05:44 PM UTC by Alkis Georgopoulos **Last Updated:** Mon Jan 03, 2022 08:08 AM UTC **Owner:** nobody The [option-lists specs](https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#option-lists) state that "the syntax for short and long POSIX options is based on the syntax supported by Python's [getopt.py](https://docs.python.org/3/library/getopt.html) module". This doesn't allow for optional or repeating arguments. A couple of examples from the [man man page](https://manpages.debian.org/bullseye/man-db/man.1.en.html#OPTIONS): ```shell --warnings[=warnings] This is an argument with an optional value -m system[,...] This is an argument with a repeating value ``` My feature request is for the square brackets `[]` to become allowed in the option lists spec and implementation in a similar way as the less than / great than symbols `<>`. This will allow us to use docutils even when some binaries in our project do need optional or repeating arguments. (I'm currently evaluating if it would be appropriate to migrate the https://ltsp.org and https://epoptes.org documentation and [man pages](https://ltsp.org/man/ltsp-image/), from markdown to restructuredtext) --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Günter M. <mi...@us...> - 2022-01-03 08:08:40
|
- **summary**: Allow optional and repeating arguments --> Allow optional and repeating arguments in option lists --- ** [feature-requests:#84] Allow optional and repeating arguments in option lists** **Status:** open **Group:** Default **Created:** Mon Nov 01, 2021 05:44 PM UTC by Alkis Georgopoulos **Last Updated:** Fri Nov 12, 2021 09:46 AM UTC **Owner:** nobody The [option-lists specs](https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#option-lists) state that "the syntax for short and long POSIX options is based on the syntax supported by Python's [getopt.py](https://docs.python.org/3/library/getopt.html) module". This doesn't allow for optional or repeating arguments. A couple of examples from the [man man page](https://manpages.debian.org/bullseye/man-db/man.1.en.html#OPTIONS): ```shell --warnings[=warnings] This is an argument with an optional value -m system[,...] This is an argument with a repeating value ``` My feature request is for the square brackets `[]` to become allowed in the option lists spec and implementation in a similar way as the less than / great than symbols `<>`. This will allow us to use docutils even when some binaries in our project do need optional or repeating arguments. (I'm currently evaluating if it would be appropriate to migrate the https://ltsp.org and https://epoptes.org documentation and [man pages](https://ltsp.org/man/ltsp-image/), from markdown to restructuredtext) --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
603 messages has been excluded from this view by a project administrator.
