EAFP - use stdlib pathlib when possible - [closed]

[jaraco]

In GitLab by @wimglenn on Dec 4, 2019, 16:32

Merges patch-1 -> master

This project metadata says pathlib2; python_version < '3' so the pathlib backport dependency might not be there in some Python 3.x (saw a crash in devpi CI due to missing pathlib2 dep)

Yes I am aware you just dropped support for 3.4 but pathlib is stdlib since 3.4 so may as well try to use it rather than intentionally restrict to > 3,5

[jaraco]

In GitLab by @jaraco on Dec 4, 2019, 23:10

As you may have noticed, the qa tests failed due to mypy#1393. One of the recommended workarounds for that bug is to revert your suggested change.

More importantly, I think that change was put in place because pathlib on Python 3.4 didn't have the full interfaces required (the backport was necessary).

Can you please file an issue describing the undesirable behavior this change intends to correct (where was the crash, on what Python version, etc)?

[jaraco]

In GitLab by @jaraco on Dec 4, 2019, 23:10

closed

[jaraco]

In GitLab by @wimglenn on Dec 5, 2019, 24:19

Hi Jason, it was something I saw in devpi's appveyor, they still support py34 for some reason. But I guess it's on them if they pull in importlib-metadata on an unsupported Python version - here's the ImportError.

Using an if-statement instead of the try/except as a way to avoid what's essentially a bug in mypy seems sub-optimal to me - why not just put an ignore until bug fixed? And if the backport was necessary due to some shortcoming in the stdlib pathlib, then a comment is sort of warranted here so it doesn't just look like an oversight.

Seeing as you've promptly closed this, and Python 3.4 support was dropped, I don't have much desire to investigate any further.

[jaraco]

In GitLab by @jaraco on Dec 5, 2019, 24:59

I closed promptly as that's my best guess as to the ultimate resolution of the issue. Given sufficient information, I (or another) may re-open this MR or prompt further discussion. I did not mean that to signal as dismissed with prejudice.

I was about to suggest kicking this back to devpi to signal that the issue lies with their tooling, but taking a quick look at the package metadata, I don't think the python_requires directive on importlib_metadata 1.1 (or 1.1.1) is correct. I'm pretty sure the specifiers indicate that python_requires!=3.4 includes 3.4.1+ and possibly even 3.4.0, which was not the intention.

[jaraco]

In GitLab by @wimglenn on Dec 5, 2019, 03:41

Ah, that thing. I can confirm that python3.4 -m pip install importlib-metadata==1.1.1 did complete install on 3.4.5 with latest pip, despite the distribution's python_requires metadata.

Yes, it's a bad trap. Thankfully the PEP 508 markers don't have this same problem as PEP 440, there we have python_version which works as you'd want and python_full_version when you need also to specify the micro.

Your proposed solution of re-releasing a micro with 3.4 support and then pulling old ones seems pragmatic, and with a bit of luck it might even unbreak that appveyor build on devpi.