Address deprecation of markdown.util.etree

[florimondmanca]

Refs encode/httpx#2313

https://python-markdown.github.io/change_log/release-3.4/

Python 3.10.0 (default, Nov 28 2021, 23:05:33) [GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import mkautodoc
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/florimond/dev/fairness/httpx/venv/lib/python3.10/site-packages/mkautodoc/__init__.py", line 1, in <module>
    from .extension import MKAutoDocExtension, makeExtension
  File "/home/florimond/dev/fairness/httpx/venv/lib/python3.10/site-packages/mkautodoc/extension.py", line 4, in <module>
    from markdown.util import etree
ImportError: cannot import name 'etree' from 'markdown.util' (/home/florimond/dev/fairness/httpx/venv/lib/python3.10/site-packages/markdown/util.py)
>>> 

https://python-markdown.github.io/change_log/release-3.4/

Previously deprecated objects have been removed

Deprecated Object	Replacement Object
markdown.util.etree	xml.etree.ElementTree

[florimondmanca]

@tomchristie I think we should merge and release this as a patch as it's breaking CI in Encode projects that use mkautodoc:

• Starlette: https://github.com/encode/starlette/runs/7425237896
• HTTPX: Pin markdown==3.3.7 to prevent mkautodoc loading failure encode/httpx#2313

I pinned the markdown dependency in HTTPX, but Starlette is now broken too. There might be other users affected.

[tomchristie]

Okay. Do you want to add a version bump as part of this PR too?

I'd probably prefer not to be maintainer of this project, as I'm not able to focus well across too many different places.

I wonder if @oprypin would be interested in pulling it in under https://github.com/mkdocs/ ?

[oprypin]

@tomchristie Thanks for the mention.

I think maybe for this instance it's simplest that you just merge this PR and make a new release, even if no other maintenance happens. I hope that doesn't take up too much time.

Or just give all rights to @florimondmanca ? They're super trustworthy and also probably by far the most prominent user of this repository/library.

Other than addressing complete breakages such as this one, I think it's fine to keep this package abandoned. I will not opt to maintain it because I'm already involved in https://github.com/mkdocstrings/mkdocstrings and I believe users can simply switch to it.

[tomchristie]

I will not opt to maintain it because I'm already involved in https://github.com/mkdocstrings/mkdocstrings and I believe users can simply switch to it.

Makes sense. I did have a bit of an attempt at switching the httpx docs over to mkdocstrings just now to see if that would be an option for us, but I couldn't get it rendering similarly enough to what we've currently got. (Other attempts from folks who have used mkdocstrings before would also be welcome.)

[oprypin]

@tomchristie

switching the httpx docs over to mkdocstrings

I think either me or @pawamoy would be glad to try and see if we can get a similar enough conversion going.
Might be good to split off to a new thread for that? mkdocstrings discussions, mkdocstrings chat or httpx issues perhaps?

[Kludex]

I've bumped on #34.

Starlette is blocked by this 😢

[Kludex]

Ah, mkdocs actually released a patch to pin Markdown. So Starlette is not blocked anymore. Thanks @oprypin 🙏

[tomchristie]

Thanks folks, now addressed in #34.