Blog plugin crashes on Python 3.8 (Netlify) #5916
Comments
|
Thanks for reporting. Indeed, Python 3.8 should still work. @facelessuser sorry to loop you in, but I'm not sure who to ask otherwise – this should also be resolved by importing |
|
@squidfunk, let me take a look |
|
What I think is happening is that |
|
I feel like this should work, but there is something quirky about Python 3.8, so it is almost guaranteed we are going ot have to do some ugly Python 3.8 specific exception. |
|
Thanks for investigating. Hmm. Meh. I'll look into it as soon as I find some time. If we can work around it somehow else, we can also replace it with a another / more compatible solution. |
|
So, this is my recommendation. Either switch out two implementations: Or use some other mapping type that doesn't have this quirk in Python 3.8. I guess you could just not specify the type for all versions of Python as well. |
|
Typing is great when it works, but when it doesn't work, I want to punch it in the face 🙃. This is one of those cases where finding the perfect solution is more work than is worth it. It may be easier to just inherit from |
|
Can't netlify build from a container? This kind of issues won't ever surface (and I strongly believe would make installation way easier) if people would just use the official container image as a default way of building docs and resorting to pypi install as a fallback |
|
So, this is what I'd probably do with the expectation that in a year, when Python 3.8 is EOL, you can just remove the else. It will maintain parity with what you have, you'll lose some type info in 3.8, but 🤷🏻 . More importantly, it should work on all Python versions. Yeah, ideally you wouldn't have to duplicate things, and if you are willing to rewrite it inheriting from something like diff --git a/material/plugins/blog/structure/options.py b/material/plugins/blog/structure/options.py
index d37779185..8d387c5ce 100644
--- a/material/plugins/blog/structure/options.py
+++ b/material/plugins/blog/structure/options.py
@@ -17,7 +17,8 @@
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
# IN THE SOFTWARE.
-
+from __future__ import annotations
+import sys
from collections import UserDict
from datetime import date, datetime, time
from mkdocs.config.base import BaseConfigOption, Config, ValidationError
@@ -27,19 +28,34 @@ from mkdocs.config.base import BaseConfigOption, Config, ValidationError
# -----------------------------------------------------------------------------
# Date dictionary
-class DateDict(UserDict[str, datetime]):
+if sys.version_info >= (3, 9):
+ class DateDict(UserDict[str, datetime]):
+
+ # Initialize date dictionary
+ def __init__(self, data: dict):
+ super().__init__(data)
- # Initialize date dictionary
- def __init__(self, data: dict):
- super().__init__(data)
+ # Initialize date of creation
+ if "created" in data:
+ self.created: datetime = data["created"]
+
+ def __getattr__(self, name: str):
+ if name in self.data:
+ return self.data[name]
+else:
+ class DateDict(UserDict):
+
+ # Initialize date dictionary
+ def __init__(self, data: dict):
+ super().__init__(data)
- # Initialize date of creation
- if "created" in data:
- self.created: datetime = data["created"]
+ # Initialize date of creation
+ if "created" in data:
+ self.created: datetime = data["created"]
- def __getattr__(self, name: str):
- if name in self.data:
- return self.data[name]
+ def __getattr__(self, name: str):
+ if name in self.data:
+ return self.data[name]
# ----------------------------------------------------------------------------- |
While running Netlify in a container may be a fine idea, this still needs to be fixed generally as it breaks when used outside a container. |
Yes, absolutely. I was more alluding to the fact that pypi-based install is marked as recommended, while, IMHO, most static-site hosters and CI's configs would be way shorter and would reduce the number of opened issues if they were using container-based installation method. |
|
Thanks for the input! I'm not a fan of the if/else solution, because if functionality is added, we need to do it in two places. Not great. Can't we just only branch on the base class? Something like: BaseDict = UserDict
if sys.version_info >= (3, 9):
BaseDict = UserDict[str, int]
class DateDict(BaseDict):
passOr does that fry the typings? I'm using |
|
That might work |
|
Thanks for your expertise and assessment! I'll give it a try. |
|
I tried it locally, it works |
I double-checked, it doesn't seem possible to do a Netlify build with an arbitrary container. You have to use one of their (two) available build containers. |
Kudos for this attitude in general and supporting such a wide range of versions (3.7+ IIRC), even when it is not convenient or nice. From a user's perspective, it really helps, e.g. some of our machines still run Debian bullseye and FreeBSD with Python 3.9 and it feels good to know that we can continue installing new versions from PyPI for a while and don't have to rush OS upgrades too much. |
|
Fixed in f2512de. Turns out there's a branchless solution: using I've tested the fix in Python 3.7, 3.8 and 3.11 – all good. |
|
Yep |
|
You can just use |
|
Released as part of 9.2.6. |
Context
I host my mkdocs site on Netlify, which currently uses Python 3.8
Bug description
When enabling the blog plugin on Python 3.8,
mkdocs buildfails withTypeError: 'ABCMeta' object is not subscriptable.Full output below:
Related links
Reproduction
9.2.5-python3.zip
Steps to reproduce
pyenv install 3.8pip install mkdocs-materialblogsection underplugins:(the info plugin wouldn't work while it was enabled, since mkdocs would error)mkdocs buildand observe the errorBrowser
No response
Before submitting
The text was updated successfully, but these errors were encountered: