Menu
▾
▴
#370 Docutils 0.15.1 Release Appears to Break Python 3 Support
Hi,
It appears as though the docutils release done yesterday to PyPi (24th July 19) to release 0.15.1 has broken Python 3 support.
Python Version is 3.5.0, platform is Windows.
From our pip install that uses sphinx 1.5.2, which depends on docutils >= 0.11:
Collecting docutils>=0.11 (from sphinx==1.5.2)
Downloading https://files.pythonhosted.org/packages/d4/12/6c3fd74a590c7327c98cae008c11d536029fa9cd7924de477e8cb8804186/docutils-0.15.1-post1.tar.gz (1.7MB)
|################################| 1.8MB 3.3MB/s
Traceback (most recent call last):
File "runpy.py", line 170, in _run_module_as_main
File "runpy.py", line 85, in _run_code
File "C:\python\Scripts\sphinx-build.exe\__main__.py", line 9, in <module>
File "c:\python\lib\site-packages\sphinx\__init__.py", line 66, in main
sys.exit(build_main(argv))
File "c:\python\lib\site-packages\sphinx\__init__.py", line 76, in build_main
from sphinx import cmdline
File "c:\python\lib\site-packages\sphinx\cmdline.py", line 19, in <module>
from docutils.utils import SystemMessage
File "c:\python\lib\site-packages\docutils\__init__.py", line 91, in <module>
class ApplicationError(StandardError): pass
NameError: name 'StandardError' is not defined
...
Everything was working perfectly yesterday, but the 0.15.1 release causes this problem everywhere.
This is causing a very large of our internal builds to break right now.
Alistair
Related
Just a note, I have updated our deployment environment to fix to 0.15.0 and the issue goes away. So the priority of this issue has dropped somewhat.
The maintenance release 0.15.1 is only required for Python 2, (fixing a circular dependency that Python 3 auto-resolves). Therefore, no Python-3 wheel was created.
The tar archives are Python-2 code that must be run through 2to3 when installing for Python 3.
See http://docutils.sourceforge.net/README.html#python-3-compatibility.
It seems that the conversion step is missing in your setup.
Does that mean then that Sphinx doesn't support python 3 out of the box as of now? Because without adding that manual step all sphinx users are going to get this error whenever they install Sphinx right?
Last edit: Alistair Evans 2019-07-25
I guess it does not matter
and one should make the py3 release,
because pip will fetch the newest source and build a local py3-wheel.
I will upload one therefore, in the coming days
Alistair Evans alistairjevans@users.sourceforge.net schrieb am Do., 25.
Juli 2019, 15:14:
Related
Bugs:
#370Ok, thank you.
NOTE: This bug affects multiple packages in various ways so I would encourage you to publish a fix for this sooner rather than later. For example, we have a Python 3 build that does not use docutils directly (ie: it is included as a transitive dependency). When we
pip installour project it reaches out topypito pull in the latest copies of all dependencies. In the process it attempts to install v0.15.1 because that is the latest version of this package, however because of the aforementioned problems (ie: regarding Python 3 packaging, etc.) the installation fails. The only workaround in the meantime is for us to go through all of our Python packages (and we manage dozens of them) and peg the revision of this transitive dependency to avoid build / runtime deployment problems, which is horrible to say the least.Also worth noting, I did see that there was a v0.15.1 version of the Python 3 package deployed to pypi but it was named "0.15.1-post1" which causes even more confusion. From what I can tell the version number in the package manifest is set to 0.15.1 but there is some sort of manual step being done when the package is deployed to rename the file such that the version identifier that is embedded in the file name has a "-post1" suffix in it. The details of this appear to be documented here:
https://sourceforge.net/p/docutils/code/8303/
This is a bad practice because there are tools in the Python toolchain which depend on the naming convention of the generated packages, so anything that attempts to parse the version information from the file will find conflicting version numbers (ie: "0.15.1" != "0.15.1.post1"). The file name should be named consistently with the version stored in the manifest file.
Also just a quick rant: the fact that this defect adversely affects MANY python packages in the community in a significantly detrimental way, I would have hoped the fix would have been implemented within minutes or hours, not days. I sincerely hope a fix can be released to pypi sooner rather than later to help mitigate these problems.
Also just to clarify / demonstrate some of the problems inherent with renaming the package file in the way I just described, consider this simple use case:
pip3 install docutilsThis will install v0.15.1 of docutils in my virtual environment:
But exporting the frozen versions to a requirements file will produce an invalid file that can not be used to re-deploy the pegged revisions of the dependencies. This believe this is a result of the renamed package file. To show how the failure is easily reproducible, simply do the following:
pip3 install docutils==0.15.1Doing so will result in the following error:
ERROR: Could not find a version that satisfies the requirement docutils==0.15.1 (from versions: 0.3, 0.3.5, 0.3.7, 0.3.9, 0.4, 0.5, 0.6, 0.7, 0.8, 0.8.1, 0.9, 0.9.1, 0.10, 0.11, 0.12, 0.13.1, 0.14rc1, 0.14rc2, 0.14, 0.15, 0.15.1.post1) ERROR: No matching distribution found for docutils==0.15.1As you can see the
post1suffix appears in the version number used for comparison purposes, which - so far as I can tell - is parsed from the file name.So long story short, I would highly recommend not renaming your packages the way you have outlined in that document I referenced earlier. It will break a lot of things.
Last edit: TheFriendlyCoder 2019-07-29
Adding support to TheFriendlyCoder posts, I can confirm this issue breaks a lot of automated build we have, using pip3 and requirements file (and docutils was referenced by another package). And by the magnitud of the issue, we were also expecting this to be solved at least during the day it was reported, hopefully the fix gets released soon, we'll be expecting this. Thanks to the team for addressing this soon.
because I skipped uploading to py2-wheel to test.pypi and installing it
into a virtualenv after of course checking the local PYTHONPATH and .cache
did not contain anything harmful ... these problems arouse
originating in having py3 code in your py2-wheel if building py3 first
and then trying to workaround things in versioning and tools that did not
exist the last time ...
On Mon, 29 Jul 2019 at 17:55, David Sanchez dsanchez-tisa@users.sourceforge.net wrote:
Related
Bugs:
#370