RapidFuzz

update pylint config for old pip versions

#313

Merged

@henryiii I followed your guide in https://scikit-hep.org/developer/style#pylint-noisy to configure pylint in the pyproject.toml. This breaks when people use relatively old versions of pip. E.g. on debian bust:

apt-get install python3-pip

installs pip version 18.1, which is unable to parse this and fails with:

pytoml.core.TomlError: /tmp/pip-install-foysvdsk/rapidfuzz/pyproject.toml(30, 7): expected_equals

You can just delete the leading parts before the dot. Pylint doesn’t require those if the inner name is unique.

I’m surprised, since I’ve got quite a few usages of this (probably more now with Ruff), and haven’t had trouble with the dot & pip. Maybe it’s because the wheels are unaffected, though.

You can just delete the leading parts before the dot. Pylint doesn’t require those if the inner name is unique.

Ah good to know. Even though there are probably no guarantees these keys actually stay unique in the future.

In this specific case pip 18.1 is unable to pick up the binary wheels and tries to build from source.
My test is:

podman run -it debian:buster-slim

> apt-get update
> apt-get install python3-dev python3-pip
> pip3 install rapidfuzz

when upgrading to the latest version using pip3 install --upgrade pip it picks up the wheel rapidfuzz-2.13.7-cp37-cp37m-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

I thought this might affect some of your packages as well.

py-version, output-format, and disable all are probably pretty safe. At least py-version moved from master to main, so I believe it's actually recommended to not put the optional section name in for that one. In fact, it's not in the current version of that page.

I'll have to think about the implications of this - with Python 3.7 hitting EoL next month, it probably is at least safe after that. I think CPython 3.7 shipped with Pip 19, at least 3.7.3+ did, so it's probably another distro messing with pip situation (like Pip 9). It's also safe on pure-Python projects. Knowing when they dropped pytoml would probably be helpful.

And yes, pip 18 can't read manylinux2014 (or even 2010) wheels. 19 added manylinux2010. That is a case were dropping support for older Python's (while you still have older manylinux builds) would have been helpful for users!

In this case it is python 3.7.3 with pip 18.1. I agree that since both Python 3.7 and debian buster are soon end of life, it probably does not matter all to much any more for future releases.

Not sure I like the fact, that they do not even update patch versions. Maybe they do maintain their own version and just backport security fixes. Still reminds me why I am not running a LTS distro on my machines ...