readthedocs/commonmark.py

Breaking change in 0.8.0 - "ImportError: No module named CommonMark"

edmorley opened this issue · 4 comments

edmorley commented

Hi!

There was a breaking change in commonmark v0.8.0 (and also present in v0.8.1), that causes our sphinx+recommonmark build to fail:

Traceback (most recent call last):
  File "/home/travis/venv/lib/python2.7/site-packages/sphinx/config.py", line 161, in __init__
    execfile_(filename, config)
  File "/home/travis/venv/lib/python2.7/site-packages/sphinx/util/pycompat.py", line 150, in execfile_
    exec_(code, _globals)
  File "/home/travis/venv/lib/python2.7/site-packages/six.py", line 709, in exec_
    exec("""exec _code_ in _globs_, _locs_""")
  File "<string>", line 1, in <module>
  File "conf.py", line 2, in <module>
    from recommonmark.parser import CommonMarkParser
  File "/home/travis/venv/src/recommonmark/recommonmark/parser.py", line 9, in <module>
    from CommonMark import Parser
ImportError: No module named CommonMark

See:
https://travis-ci.org/mozilla/treeherder/jobs/425655351#L641

Our requirements file (that has now been pinned to commonmark 0.7.5, the last release that works with recommonmark master) is here:
https://github.com/mozilla/treeherder/blob/817ac227f3cd6b2dfeb049f853b68269552a2964/requirements/docs.txt

I believe this was due to #131.

Would it be possible to revert that PR, release a 0.8.2 that supports the old module name, and then remove the symlink in 1.0.0 instead? (I'll also file an issue against recommonmark for adding an upper bound on their range of <1 and/or adjusting their import)

nikolas commented

As of version 0.8.1, you need to replace all instances of CommonMark with commonmark.

edmorley commented

Hi! That's a breaking change - hence filing this issue.
Please could you take another look?

edmorley commented

Or to be extra clear:

Making breaking changes in minor version releases is not ideal. This issue was requesting that a new 0.8.x be released with the breaking change reverted, and then the breaking change be re-released afterwards in v1.0.

nikolas commented

I recommend staying at version 0.7.x if you're using the CommonMark package name, see: #134 (comment)

As far as releasing new version to revert changes - if someone else wants to handle it that's cool, but personally I just don't put much importance in versioning schemes.

  • 😕1