Issue with jupyter-book 0.11 and pip-compile

[molpopgen]

maintainer summary: jazzband/pip-tools#1372, is causing pip-compile to currently fail with jupyter-book v0.11, this should be fixed with jupyter-book v0.12

---

Describe the bug

The pinning of markdown-it-py is inconsistent.

To Reproduce

molpopgen@pop-os:/venvs$ python3 -m venv test
molpopgen@pop-os:/venvs$ source test/bin/activate
(test) molpopgen@pop-os:/venvs$ echo "jupyter-book" > requirements.txt
(test) molpopgen@pop-os:/venvs$ pip install pip-tools
Collecting pip-tools
  Using cached pip_tools-6.1.0-py3-none-any.whl (44 kB)
Collecting click>=7
  Using cached click-8.0.1-py3-none-any.whl (97 kB)
Collecting pip>=20.3
  Using cached pip-21.1.2-py3-none-any.whl (1.5 MB)
Collecting pep517
  Using cached pep517-0.10.0-py2.py3-none-any.whl (19 kB)
Collecting toml
  Using cached toml-0.10.2-py2.py3-none-any.whl (16 kB)
Installing collected packages: click, pip, toml, pep517, pip-tools
  Attempting uninstall: pip
    Found existing installation: pip 20.1.1
    Uninstalling pip-20.1.1:
      Successfully uninstalled pip-20.1.1
Successfully installed click-8.0.1 pep517-0.10.0 pip-21.1.2 pip-tools-6.1.0 toml-0.10.2
(test) molpopgen@pop-os:/venvs$ pip-compile requirements.txt 
Could not find a version that matches markdown-it-py~=0.6.0,~=0.6.2,~=1.0 (from jupytext==1.10.3->jupyter-book==0.11.1->-r requirements.txt (line 1))
Tried: 0.1.0, 0.1.0, 0.1.1, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.4.0, 0.4.1, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6, 0.4.7, 0.4.7, 0.4.8, 0.4.8, 0.4.9, 0.4.9, 0.5.0, 0.5.0, 0.5.1, 0.5.1, 0.5.2, 0.5.2, 0.5.3, 0.5.3, 0.5.4, 0.5.4, 0.5.5, 0.5.5, 0.5.6, 0.5.6, 0.5.7, 0.5.7, 0.5.8, 0.5.8, 0.6.0, 0.6.0, 0.6.1, 0.6.1, 0.6.2, 0.6.2, 1.0.0, 1.0.0, 1.1.0, 1.1.0
Skipped pre-versions: 1.0.0b1, 1.0.0b1, 1.0.0b2, 1.0.0b2, 1.0.0b3, 1.0.0b3
There are incompatible versions in the resolved dependencies:
  markdown-it-py~=0.6.2 (from myst-parser==0.13.7->myst-nb==0.12.3->jupyter-book==0.11.1->-r requirements.txt (line 1))
  markdown-it-py~=1.0 (from mdit-py-plugins==0.2.8->myst-parser==0.13.7->myst-nb==0.12.3->jupyter-book==0.11.1->-r requirements.txt (line 1))
  markdown-it-py~=0.6.0 (from jupytext==1.10.3->jupyter-book==0.11.1->-r requirements.txt (line 1))

Expected behavior

I expected a consistent set of pinned dependencies that I could store in a requirements.txt file.

Environment

Python 3.8.6 on Pop OS 20.04

[welcome]

Thanks for opening your first issue here! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out EBP's Code of Conduct. Also, please try to follow the issue template as it helps other community members to contribute more effectively.

If your issue is a feature request, others may react to it, to raise its prominence (see Feature Voting).

Welcome to the EBP community! 🎉

[chrisjsewell]

Heya, well I would suggest you should not be trying to manually create a requirements.txt with all of the requirements pinned to specific versions (aka a lock file); with any packages this will inevitably lead to inconsistencies. Instead, you could simply run in fresh virtual environment something like pip install jupyter-book--0.11.1 jupytext, then run pip freeze to generate the contents of the requirements.txt. Alternatively there are tools like https://python-poetry.org that will generate a lock file for you.

In terms, of jupyter-book not yet supporting markdown-it-py v1, this is known (I was the one who upgraded markdown-it-py and also jupytext to use v1), we are just upgrading the rest of the stack first (e.g. executablebooks/MyST-Parser@fb8c8fd and executablebooks/MyST-NB#320) then will update jupyter-book relatively shortly.

[grahamgower]

Hi @chrisjsewell. Here's a fun thing for you to try: pip install "attrs>21" jupyter-book. You might want to get a coffee or 10 while you wait.

[chrisjsewell]

Well yes that's because markdown-it-py 0.6 does not support attrs>21. The resolution time is an issue you can raise with pip, but again the point is, if you literally hard-code package versions that are incompatible, you can never hope to get a compatible environment. jupyter-book will always end up being "out of date" with respect to one package or another, this is not a problem because it is why we have semantic versioning, but equally you should not expect to be able to have a requirements.txt with a pinning to the latest version of every package and it automatically be consistent

[molpopgen]

There are many good reasons to lock dependencies using pip-compile. Docker deployment, for example. The reason why pip freeze is not a great idea is nicely explained here. The problem here is that jupyter-book is relying in internally-inconsistent dependencies, which is a bug--either the dependency causing the conflict is incompatible with the previous version or it is not. In either case, the correct pinning would be >= the lower version number.

[chrisjsewell]

The problem here is that jupyter-book is relying in internally-inconsistent dependencies

What do you believe to be the internally-inconsistent dependencies?

[molpopgen]

What do you believe to be the internally-inconsistent dependencies?

See the errors above--the situation cannot be satisfied.

[chrisjsewell]

In either case, the correct pinning would be >= the lower version number.

That is an extremely bad idea and against semantic versioning, since it would mean that every time a dependent package made a breaking change it would break jupyter-book

[molpopgen]

That is an extremely bad idea and against semantic versioning, since it would mean that every time a dependent package made a breaking change it would break jupyter-book

It is not at all against sem ver. Tests would be catching the breaking changes. But this is not a jupyter-book issue (which is a program), but rather with the libraries it uses. Typically, one does not expect == or ~= pinning for libraries in the setup.cfg files in Python. (rust et al. are a different world where this is, in fact, idiomatic.)

[chrisjsewell]

See the errors above--the situation cannot be satisfied.

Firstly jupytext is not a dependency of jupyter-book, i.e. you can use jupyter-book without jupytext. It's commonly used with it though, so we could certainly consider having a pinned version in an extra.

Secondly, both jupyter-book (via myst-nb) and jupytext clearly specify the versions of markdown-it-py they work with, for all releases. As I have already suggested you need to lower your version of jupytext to one that supports markdown-it-py v0.6

[molpopgen]

Firstly jupytext is not a dependency of jupyter-book, i.e. you can use jupyter-book without jupytext. It's commonly used with it though, so we could certainly consider having a pinned version in an extra.

This is false, in the sense that it comes into an empty venv with a simple pip install jupyter-book:

(jbook) molpopgen@pop-os:~/venvs$ pip show jupytext
Name: jupytext
Version: 1.10.3
Summary: Jupyter notebooks as Markdown documents, Julia, Python or R scripts
Home-page: https://github.com/mwouts/jupytext
Author: Marc Wouts
Author-email: marc.wouts@gmail.com
License: MIT
Location: /home/molpopgen/venvs/jbook/lib/python3.8/site-packages
Requires: nbformat, toml, markdown-it-py, pyyaml
Required-by: jupyter-book
``

[chrisjsewell]

Typically, one does not expect == or ~= pinning for libraries in the setup.cfg files in Python.

I'm afraid I very much disagree with you expectations here.

Again there is nothing wrong with the specifications of the dependencies here, they all clearly specify for every release what dependencies they work with. Unfortunately pip, although improving, is still not perfect at dependency resolution. If you had installed via Conda that is at actually better at doing this resolution.

[molpopgen]

In fact, jupytext is part of install_requires:

jupyter-book/setup.cfg

Line 37 in ff51015

install_requires =

[chrisjsewell]

Oh wait is mdit-py-plugins==0.2.8 what you have pinned to? (can I see your requirements.txt?) because thats actually where the inconsistency is coming from (as it does say in the error message), it needs to be <=0.2.6.
Basically I'm a bit confused by how you actually created your requirements.txt in the first place, did you do it by hand?

[choldgraf]

an aside - this makes me wonder if we should move the dependency on jupytext here:

jupyter-book/setup.cfg

Line 42 in ff51015

jupytext>=1.8,<1.11

to an optional dependency. In the codebase, I think the only place where we use jupytext is in a utility function, and this itself uses a try: except: block to catch if it is installed:

jupyter-book/jupyter_book/utils.py

Line 55 in cbafb54

def init_myst_file(path, kernel, verbose=True):

I'm not sure where/when we decided to add jupytext as a dependency (maybe it is a carry-over from the past?) and the discussion here makes me think that it isn't needed

[chrisjsewell]

an aside - this makes me wonder if we should move the dependency on jupytext here

Yeh I would have to look for when why/why its added, in case there is/was a good reaon.

But yeh its actually nothing to do with jupytext, that was a red herring. its seeming likely because of the mdit-py-plugins==0.2.8 pinning in @molpopgen requirements.txt

[molpopgen]

But yeh its actually nothing to do with jupytext, that was a red herring. its seeming likely because of the mdit-py-plugins==0.2.8 pinning in @molpopgen requirements.txt

No, this is not correct. The only thing in the requirements file is jupyter-book, as shown in the reproducible example above.

[molpopgen]

Basically I'm a bit confused by how you actually created your requirements.txt in the first place, did you do it by hand?

See the reproducible example above, specifically the echo command. I created an empty venv and then, in and empty directory, added jupyter-book to a 1-liner requirements.txt, then ran pip-compile. There's literally nothing else there other than pip-tools.

[chrisjsewell]

abd so what output do you get when you run pip freeze?

[chrisjsewell]

On a quick check, it seems to be related to: jazzband/pip-tools#1372, i.e. " That's because pip-tools doesn't yet have a proper dependency resolver."

If you simply run pip -rrequirements.txt does it create a valid environment?

[molpopgen]

On a quick check, it seems to be related to: jazzband/pip-tools#1372, i.e. " That's because pip-tools doesn't yet have a proper dependency resolver."

If you simply run pip -rrequirements.txt does it create a valid environment?

Yes, it is related, but I also agree somewhat with the author of pip-tools there.

pip-installing the 1-line requirements.txt file does work (which we did already know), and gives the following ERROR:

ERROR: mdit-py-plugins 0.2.8 has requirement markdown-it-py~=1.0, but you'll have markdown-it-py 0.6.2 which is incompatible.
ERROR: sphinx-external-toc 0.2.0 has requirement click~=7.1, but you'll have click 8.0.1 which is incompatible.

Note that this new venv does not have pip-tools, and some of these issues are in the jupyter-book chain:

pip show click
Name: click
Version: 8.0.1
Summary: Composable command line interface toolkit
Home-page: https://palletsprojects.com/p/click/
Author: Armin Ronacher
Author-email: armin.ronacher@active-4.com
License: BSD-3-Clause
Location: /home/molpopgen/venvs/jbook/lib/python3.8/site-packages
Requires: 
Required-by: sphinx-external-toc, sphinx-book-theme, jupyter-book

In the end, I've hacked the production requirements file to "work", but it is unclear how generally this will work. If some subset of jupyter-book really does need markdown-it-py~=1.0.x, then that'll break w/o warning. Is jupyter-book tested sufficiently well such that this output from pip-compile can be treated as a false positive:

pip-compile requirements.in 
Could not find a version that matches markdown-it-py~=0.6.0,~=0.6.2,~=1.0 (from jupytext==1.10.3->jupyter-book==0.11.1->-r requirements.in (line 1))
Tried: 0.1.0, 0.1.0, 0.1.1, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.4.0, 0.4.1, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6, 0.4.7, 0.4.7, 0.4.8, 0.4.8, 0.4.9, 0.4.9, 0.5.0, 0.5.0, 0.5.1, 0.5.1, 0.5.2, 0.5.2, 0.5.3, 0.5.3, 0.5.4, 0.5.4, 0.5.5, 0.5.5, 0.5.6, 0.5.6, 0.5.7, 0.5.7, 0.5.8, 0.5.8, 0.6.0, 0.6.0, 0.6.1, 0.6.1, 0.6.2, 0.6.2, 1.0.0, 1.0.0, 1.1.0, 1.1.0
Skipped pre-versions: 1.0.0b1, 1.0.0b1, 1.0.0b2, 1.0.0b2, 1.0.0b3, 1.0.0b3
There are incompatible versions in the resolved dependencies:
  markdown-it-py~=0.6.0 (from jupytext==1.10.3->jupyter-book==0.11.1->-r requirements.in (line 1))
  markdown-it-py~=0.6.2 (from myst-parser==0.13.7->myst-nb==0.12.3->jupyter-book==0.11.1->-r requirements.in (line 1))
  markdown-it-py~=1.0 (from mdit-py-plugins==0.2.8->myst-parser==0.13.7->myst-nb==0.12.3->jupyter-book==0.11.1->-r requirements.in (line 1))

In other words, all all 3 of those markdown-it-py versions included in the CI?

The output of pip freeze is:

alabaster==0.7.12
anyio==3.1.0
argon2-cffi==20.1.0
async-generator==1.10
attrs==20.3.0
Babel==2.9.1
backcall==0.2.0
beautifulsoup4==4.9.3
bleach==3.3.0
certifi==2021.5.30
cffi==1.14.5
chardet==4.0.0
click==8.0.1
colorama==0.4.4
decorator==5.0.9
defusedxml==0.7.1
docutils==0.16
entrypoints==0.3
gitdb==4.0.7
GitPython==3.1.17
idna==2.10
imagesize==1.2.0
importlib-metadata==4.5.0
importlib-resources==5.1.4
ipykernel==5.5.5
ipython==7.24.1
ipython-genutils==0.2.0
ipywidgets==7.6.3
jedi==0.18.0
Jinja2==3.0.1
jsonschema==3.2.0
jupyter-book==0.11.1
jupyter-cache==0.4.2
jupyter-client==6.1.12
jupyter-core==4.7.1
jupyter-server==1.8.0
jupyter-server-mathjax==0.2.3
jupyter-sphinx==0.3.2
jupyterbook-latex==0.3.1
jupyterlab-widgets==1.0.0
jupytext==1.10.3
latexcodec==2.0.1
linkify-it-py==1.0.1
markdown-it-py==0.6.2
MarkupSafe==2.0.1
matplotlib-inline==0.1.2
mdit-py-plugins==0.2.8
mistune==0.8.4
myst-nb==0.12.3
myst-parser==0.13.7
nbclient==0.5.3
nbconvert==5.6.1
nbdime==3.1.0
nbformat==5.1.3
nest-asyncio==1.5.1
notebook==6.4.0
packaging==20.9
pandocfilters==1.4.3
parso==0.8.2
pexpect==4.8.0
pickleshare==0.7.5
prometheus-client==0.11.0
prompt-toolkit==3.0.18
ptyprocess==0.7.0
pybtex==0.24.0
pybtex-docutils==1.0.0
pycparser==2.20
pydata-sphinx-theme==0.6.3
Pygments==2.9.0
pyparsing==2.4.7
pyrsistent==0.17.3
python-dateutil==2.8.1
pytz==2021.1
PyYAML==5.4.1
pyzmq==22.1.0
requests==2.25.1
Send2Trash==1.5.0
six==1.16.0
smmap==4.0.0
sniffio==1.2.0
snowballstemmer==2.1.0
soupsieve==2.2.1
Sphinx==3.5.4
sphinx-book-theme==0.1.0
sphinx-comments==0.0.3
sphinx-copybutton==0.3.1
sphinx-external-toc==0.2.0
sphinx-panels==0.5.2
sphinx-thebe==0.0.8
sphinx-togglebutton==0.2.3
sphinxcontrib-applehelp==1.0.2
sphinxcontrib-bibtex==2.2.1
sphinxcontrib-devhelp==1.0.2
sphinxcontrib-htmlhelp==2.0.0
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-qthelp==1.0.3
sphinxcontrib-serializinghtml==1.1.5
SQLAlchemy==1.3.24
terminado==0.10.0
testpath==0.5.0
toml==0.10.2
tornado==6.1
traitlets==5.0.5
uc-micro-py==1.0.1
urllib3==1.26.5
wcwidth==0.2.5
webencodings==0.5.1
websocket-client==1.0.1
widgetsnbextension==3.5.1
zipp==3.4.1

[chrisjsewell]

Yeh that's definitely it I think, there is no problem installing jupyter-book with pip or Conda; its a surprise to me TBH, because I have used pip-compile before with no issues, but I'm not sure how it is supposed to work properly without a dependency resolver, given that is a core part of its functionality

So yes pip-compile cannot be used at this time until either (a) pip-tools fixes its bug or (b) jupyter-book starts depending on markdown-it-py v1 (which will anyhow be relatively soon)

[molpopgen]

but I'm not sure how it is supposed to work properly without a dependency resolver

The dependency resolution is mathematically impossible in this case. A version cannot simultaneously be both ~=1.0 and ~=0.6.x`. That's the crux of the issue.

[chrisjsewell]

Yes, it is related, but I also agree somewhat with the author of pip-tools there.

What comment are you referring to by the pip-tools author? From what I read in the issues they all seem in agreement that need a resolver (and one will be implemented)

[molpopgen]

What comment are you referring to by the pip-tools author? From what I read in the issues they all seem in agreement that need a resolver (and one will be implemented)

The one linked to above, re: pip freeze. One eventually gets there by following through the various issues related to the one you linked to.

[chrisjsewell]

The dependency resolution is mathematically impossible in this case. A version cannot simultaneously be both ~=1.0 and ~=0.6.x`. That's the crux of the issue.

No thats is only because, for some reason pip-compile decides to pin mdit-py-plugins==0.2.8, which then enforces markdown-it-py v1. Both pip and conda correctly identify mdit-py-plugins==0.2.6 as the compatible version to install. Hence, why us or no one else has had this specific issue, it is only becuase pip-tools is not correctly resolving dependencies

[chrisjsewell]

The long and the short of it is; don't rely on pip-compile until jazzband/pip-tools#1372 is fixed, because without it, it simply does not work.

If you want a lock-file for jupyter-book 0.11.1 that actually works:

alabaster==0.7.12
anyio==3.1.0
appnope==0.1.2
argon2-cffi==20.1.0
async-generator==1.10
attrs==20.3.0
Babel==2.9.1
backcall==0.2.0
beautifulsoup4==4.9.3
bleach==3.3.0
certifi==2021.5.30
cffi==1.14.5
chardet==4.0.0
click==7.1.2
colorama==0.4.4
decorator==5.0.9
defusedxml==0.7.1
docutils==0.16
entrypoints==0.3
gitdb==4.0.7
GitPython==3.1.17
idna==2.10
imagesize==1.2.0
importlib-metadata==4.5.0
importlib-resources==5.1.4
ipykernel==5.5.5
ipython==7.24.1
ipython-genutils==0.2.0
ipywidgets==7.6.3
jedi==0.18.0
Jinja2==3.0.1
jsonschema==3.2.0
jupyter-book==0.11.1
jupyter-cache==0.4.2
jupyter-client==6.1.12
jupyter-core==4.7.1
jupyter-server==1.8.0
jupyter-server-mathjax==0.2.3
jupyter-sphinx==0.3.2
jupyterbook-latex==0.3.1
jupyterlab-widgets==1.0.0
jupytext==1.10.3
latexcodec==2.0.1
linkify-it-py==1.0.1
markdown-it-py==0.6.2
MarkupSafe==2.0.1
matplotlib-inline==0.1.2
mdit-py-plugins==0.2.6
mistune==0.8.4
myst-nb==0.12.3
myst-parser==0.13.7
nbclient==0.5.3
nbconvert==5.6.1
nbdime==3.1.0
nbformat==5.1.3
nest-asyncio==1.5.1
notebook==6.4.0
packaging==20.9
pandocfilters==1.4.3
parso==0.8.2
pexpect==4.8.0
pickleshare==0.7.5
prometheus-client==0.11.0
prompt-toolkit==3.0.18
ptyprocess==0.7.0
pybtex==0.24.0
pybtex-docutils==1.0.0
pycparser==2.20
pydata-sphinx-theme==0.6.3
Pygments==2.9.0
pyparsing==2.4.7
pyrsistent==0.17.3
python-dateutil==2.8.1
pytz==2021.1
PyYAML==5.4.1
pyzmq==22.1.0
requests==2.25.1
Send2Trash==1.5.0
six==1.16.0
smmap==4.0.0
sniffio==1.2.0
snowballstemmer==2.1.0
soupsieve==2.2.1
Sphinx==3.5.4
sphinx-book-theme==0.1.0
sphinx-comments==0.0.3
sphinx-copybutton==0.3.1
sphinx-external-toc==0.2.0
sphinx-panels==0.5.2
sphinx-thebe==0.0.8
sphinx-togglebutton==0.2.3
sphinxcontrib-applehelp==1.0.2
sphinxcontrib-bibtex==2.2.1
sphinxcontrib-devhelp==1.0.2
sphinxcontrib-htmlhelp==2.0.0
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-qthelp==1.0.3
sphinxcontrib-serializinghtml==1.1.5
SQLAlchemy==1.3.24
terminado==0.10.0
testpath==0.5.0
toml==0.10.2
tornado==6.1
traitlets==5.0.5
uc-micro-py==1.0.1
urllib3==1.26.5
wcwidth==0.2.5
webencodings==0.5.1
websocket-client==1.0.1
widgetsnbextension==3.5.1
zipp==3.4.1

[molpopgen]

No thats is only because, for some reason pip-compile decides to pin mdit-py-plugins==0.2.8, which then enforces markdown-it-py v1. Both pip and conda correctly identify mdit-py-plugins==0.2.6 as the compatible version to install. Hence, why us or no one else has had this specific issue, it is only becuase pip-tools is not correctly resolving dependencies

This is because myst-parser is pinning it to 0.2.8: https://github.com/executablebooks/MyST-Parser/blob/master/setup.cfg#L43

pip show mdit-py-plugins
Name: mdit-py-plugins
Version: 0.2.8
Summary: Collection of plugins for markdown-it-py
Home-page: https://github.com/executablebooks/mdit-py-plugins
Author: Chris Sewell
Author-email: chrisj_sewell@hotmail.com
License: MIT
Location: /home/molpopgen/venvs/jbook/lib/python3.8/site-packages
Requires: markdown-it-py
Required-by: myst-parser, markdown-it-py

[molpopgen]

This is because myst-parser is pinning it to 0.2.8: https://github.com/executablebooks/MyST-Parser/blob/master/setup.cfg#L43

Actually, no--that's the requirement for the latest version. Checking the older now.

[molpopgen]

No thats is only because, for some reason pip-compile decides to pin mdit-py-plugins==0.2.8, which then enforces markdown-it-py v1. Both pip and conda correctly identify mdit-py-plugins==0.2.6 as the compatible version to install. Hence, why us or no one else has had this specific issue, it is only becuase pip-tools is not correctly resolving dependencies

Okay, I think I see what's happening now. I traced myst-parser back to 0.13.7 and it pins mdit-py-plugins to 0.2.5.

[chrisjsewell]

I traced myst-parser back to 0.13.7 and it pins mdit-py-plugins to 0.2.5.

Exactly and that works fine with markdown-it-py v0.6.
In all honesty (with hindsight), yeh I probably should have changed mdit-py-plugins to 0.3 when I changed it to depend on markdown-it-py v1, but at the same time I know all of this stuff works together with both pip and conda, since I wrote the requirements files for all of them: markdown-it-py, mdit-py-plugins, myst-parser, myst-nb, jupytext and juyter-book

[choldgraf]

follow-up: I've got a PR to see what happens if we remove jupytext...I don't suspect it will be a problem (though we use it in our documentation) #1353

[chrisjsewell]

I've got a PR to see what happens if we remove jupytext.

yeh but then I can see people getting the wrong version of jupytext and everything will break. Again jupytext is actually nothing to do with the issue here.

[chrisjsewell]

But yeh though absolutely thanks for bringing it to our attention (this issue with pip-compile) @molpopgen
I'm not sure though we can start testing in all our packages, that things are compatible with pip-compile (on top of pip and conda)

[molpopgen]

Thanks for helping me work through it. It is frustrating that it finds the wrong answer--this is the first one in a long time of using it to manage all the CI environments for a few projects.

[chrisjsewell]

well, as you can see lol, its also frustrating for me, since I have gone to great pains to ensure all the dependency pieces fit together 🥴. But yeh come v0.12, this should all clear up, and then the point of releasing markdown-it-py v1 was that it should be pretty stable now and rarely incur any further breaking changes.

[mdekstrand]

Just FYI, this problem also arises when using pipenv to manage a project's environment. I have worked around it with direct, restricted dependency on mdit-py-plugins:

[packages]
jupyter-book = "==0.11.*"
mdit-py-plugins = "<0.2.7"