mkdocs-material@8.2.12 requires python >= 3.7 instead of python 3.6
See original GitHub issueContribution guidelines
- I’ve read the contribution guidelines and wholeheartedly agree
I’ve found a bug and checked that …
- … the problem doesn’t occur with the
mkdocs
orreadthedocs
themes - … the problem persists when all overrides are removed, i.e.
custom_dir
,extra_javascript
andextra_css
- … the documentation does not mention anything about my problem
- … there are no open or closed issues that are related to my problem
Description
Installing mkdocs-material@8.2.12
on an environment with python 3.6 would fail because one of the dependencies pymdown-extensions
is now required to be >=9.4
. However, since pymdown-extensions@9.2
, it has dropped support for python 3.6 and now requires python 3.7 or above.
Here’s the error message:
Could not find a version that satisfies the requirement pymdown-extensions>=9.4 (from mkdocs-material) (from versions: 1.0.0, 1.0.1, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.6.1, 1.7, 1.8, 2.0, 3.0, 3.1, 3.2, 3.2.1, 3.3, 3.4, 3.5, 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.5.1, 4.6, 4.7, 4.8, 4.9, 4.9.1, 4.9.2, 4.10, 4.10.1, 4.10.2, 4.11, 4.12, 5.0, 6.0, 6.1, 6.2, 6.2.1, 6.3, 7.0b1, 7.0b2, 7.0rc1, 7.0rc2, 7.0, 7.1, 8.0, 8.0.1, 8.1, 8.1.1, 8.2, 9.0.dev0, 9.0, 9.1)
No matching distribution found for pymdown-extensions>=9.4 (from mkdocs-material)
Expected behaviour
Install mkdocs-material on python 3.6 environment would succeed (i.e. it installs mkdocs-material@8.2.11, which is the last version that support python 3.6)
Actual behaviour
It fails with the error message mentioned in description
Steps to reproduce
On an environment with python 3.6, run
pip3 install mkdocs-material
Package versions
- Python:
python3 --version
: 3.6.9 - MkDocs:
mkdocs --version
: unrelated - Material:
pip show mkdocs-material | grep -E ^Version
: unrelated
Configuration
Unrelated
System information
- Operating system: Ubuntu 18.04
- Browser: Unrelated
Issue Analytics
- State:
- Created a year ago
- Comments:12 (9 by maintainers)
Top Results From Across the Web
pipenv requires python 3.7 but installed version is 3.8 and ...
I have Python 3.9 installed,. and pipenv requires Python 3.6 as stated in pipfile. So, I change ...
Read more >What's New In Python 3.7 — Python 3.11.1 documentation
This article explains the new features in Python 3.7, compared to 3.6. Python 3.7 was released on June 27, 2018. For full details,...
Read more >Python Release Python 3.7.0
Python 3.7.0. Release Date: June 27, 2018. Note: The release you are looking at is Python 3.7.0, the initial feature release for the...
Read more >Python Release Python 3.6.7
Python 3.6.7. Release Date: Oct. 20, 2018. Note: The release you are looking at is Python 3.6.7, a bugfix release for the legacy...
Read more >What's New In Python 3.12 — Python 3.12.0a3 documentation
import ...' instead? ImportError exceptions raised from failed from <module> import <name> ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I have no interest to maintain a Python 3.6 compatible version, as this is an uphill battle with more of our upstream dependencies moving on to higher versions. Remember that Material for MkDocs is a leaf dependency – we have almost no dependents, but we depend on several other packages. However, Material for MkDocs is Open Source, so I imagine that this can surely be done as part of a fork by somehow who is familiar with the Python ecosystem.
For the time being, you can pin the version to 8.2.11, as this is the last one working with Python 3.6.
Ah, so you want a final version of mkdocs that you can pin that will work for Python 3.6 always. Material would have to pin all the versions of everything to make sure that is the case since it is not the bottom of the stack. It’d have to pin its dependencies and the dependencies of all of those dependencies. Something can surely break things in the future. I’m sure a Py3.6 compatible release that works with things as they are right now with minimal effort could be created, but I’ll leave that up to @squidfunk to decide.
If Material was interested in ensuring no future breakage for specific Python versions, it may be in its interest to create some test jobs that install the package on various Python versions. Since there are currently no tests to do this, stuff like this will probably happen again. But even then, things can retroactively break unless your package is at the bottom of the stack.