On Thu, Feb 03, 2022 at 11:34:26PM +0100, Pierre-Elliott Bécue wrote: > Hi Michael, > > > Since Mistune 2.0.0 regresses its support for standard markdown, I ask > > that a separate package be made for mistune 2.x to give more time for > > mistune 0.8.x users to migrate to mistune 2.x or another library entirely. > > > > Cheers, > > I'm not formally against it, but it's not really standard in my > opinion. It'd lead to maintenance of two packages, probably on some long > term (as it'd relieve the pressure to migrate for maintainers of > reverse-deps of mistune). > > Besides, having a source package named "mistune2" while upstream's > package is named "mistune" adds also another layer of complexity. > > I'd like to have some python team members' opinion on this, and I am not > sure to be eager to do it as of now.
I agree that this sounds like a terrible idea. What would the Python module be called in a separate python3-mistune2 package be called? If it were called mistune, then python3-mistune2 would have to conflict with python3-mistune (or "python3-mistune0.84" or similar), and there would be little benefit. If the module itself were renamed to mistune2, then the Debian mistune package would be incompatible with any other software requiring mistune. Basically, the mistune upstream author has completely messed up on this by making what is essentially a completely different package with superficially similar functionality but the same name. What the Debian nbconvert maintainers have done is to vendor mistune 0.8.4: they now include it as _mistune.py within the Debian package, and have nbconvert do "import nbconvert.filters._mistune as mistune" (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py). That seems like an eminently sensible solution to this problem. Maybe not ideal, but it will work until the upstream maintainers find a way to work with mistune 2.0.x. Best wishes, Julian
