pythonfinder crashes when system has Python 2.7.15+

[paulproteus]

Hi there,

I've noticed that on Ubuntu 18.10, pyfinder --findall crashes. I've submitted a fix at pypa/packaging#150 but wanted to leave a note here in case someone Googles the issue and wonders what's going on.

I'll close the issue here once that one is resolved, or we can discuss alternate ways to fix it within pythonfinder.

Best wishes!

[techalchemy]

I’m guessing we are bad and should feel bad. What makes a versions specifier valid for python? I had no idea there was any system using +foo notation in a distributed release of cpython

Note that we have 0 tests against this library specifically and all of our tests are done via integration downstream in pipenv so it’s easy to miss things like this

[njsmith]

It's not too uncommon for distributors to ship a slightly patched version of projects like Python, and then they have... idiosyncratic ways of recording that. In this case I think Ubuntu is shipping something like a snapshot they pulled from the 2.7 dev branch, in order to include fixes that are more recent than the last 2.7 release, so "2.7.15+" means something like "a release in between 2.7.15 and 2.7.16".

Other times I've run into this kind of issue:

• Upstream kernel releases have versions like "3.13.0" for the main release, and then "3.13.x" for official stable patch releases. But Debian, like many distributors, has their own branch to manage patches on top of the main releases, that doesn't necessarily match the official stable patch releases. (The kernel is weird... historically there were no official patch releases, and the various distros all did their own QA and maintained their own stable forks.) Anyway, because their releases didn't necessarily correspond to any particular 3.13.x release, Debian's kernels reported their version as being something like "3.13-1", which is accurate and informative and broke stuff. They had to start adding a bogus 3rd dotted component, like "3.13.0-1", just for compatibility.

• The manylinux support in pip has to parse the glibc version to figure out whether the system it's running on is new enough to support manylinux wheels. This is easy, because glibc versions are just like "2.20". Except... when they're not: Install Error in Synology DSM 6.0 pypa/pip#3588. To cope with this we had to switch to some more robust version parsing: https://github.com/pypa/pip/blob/3a77bd667cc68935040563e1351604c461ce5333/src/pip/_internal/utils/glibc.py#L44-L52

That glibc version parsing code might be good enough for this case too? Depends on what you're trying to do.

[techalchemy]

see pypa/pipenv#3241 pypa/pipenv#3232

@njsmith it's entirely likely that we can take advantage of the glibc.py parsing code, or at least just discarding the irrelevant portions. Thanks for the tip as always

[paulproteus]

Thanks @techalchemy ! :D

[paulproteus]

& thanks @njsmith and hi maybe we met at PyCon if you're the nice Trio person!

[techalchemy]

That’s him :) he is very modest but he is a visionary and his thoughts about concurrency are playing a major role in redefining concurrent programming in numerous programming languages, I’m still flattered he is watching my projects

[njsmith]

👋 ☺️

@techalchemy I didn't realize you had access to sys and were parsing sys.version – you might find it easier to use sys.version_info, which has all the info you need in a nice structured form?

>>> sys.version
'2.7.15+ (default, Oct  2 2018, 22:12:08) \n[GCC 8.2.0]'
>>> sys.version_info
sys.version_info(major=2, minor=7, micro=15, releaselevel='final', serial=0)

[techalchemy]

version_info isn’t helpful on all versions of python, for some non-cpython implementations it is slightly different as I recall or else I can’t think of a reason I wouldn’t have used it :/

In any event the string doesn’t always come from invoking python which can have considerable overhead, I have some heuristics to try and pick out the version from the path if I think I’m dealing with python