Add a specifier for alerts that are linked to a library

[PeterHamfelt]

Current problem

I'm trying to find a solution to specify an alert which is specific to a given library and version of that library.
An example is the pylint-ml plugin which has checkers associated with the Pandas library.
pylint-dev/pylint-ml#23

Desired solution

When creating a checker, I would like to be able to add

• which library the code smell/alert is associated to
• which version of the lib ?below/exact/above? it is linked to

The question I have is how can we check which lib version the user is using or does this need to be configured manually?
I am open to suggestions :)

Additional context

No response

[mbyrnepr2]

Hi @PeterHamfelt perhaps this could be relevant to your question -

The question I have is how can we check which lib version the user is using or does this need to be configured manually?
I am open to suggestions :)

>>> from importlib.metadata import version
>>> version("pandas")
'2.2.1'
>>> 

https://docs.python.org/3/library/importlib.metadata.html

[Pierre-Sassoulas]

Thank you Marc ! I think we also need to specify how we handle the message declaration of the lib version in the checker (this is already done for python version we can build on it).

Example of use for the current minversion:

from pylint.checkers import BaseChecker

class AsyncChecker(BaseChecker):
    msgs = {
        "E1700": (
            "Yield inside async function",
            "yield-inside-async-function",
            "Used when an `yield` or `yield from` statement is "
            "found inside an async function.",
            {"minversion": (3, 5)},
        ),
    }

... But we must also declare what lib(s) is (are) affected. So possible data structure:

from pylint.checkers import BaseChecker

class PandasNumpyChecker(BaseChecker):
    msgs = {
        "E0042": (
            "Some pandas/numpy version specific message",
            "pandas-numpy-message",
            "Some pandas/numpy version specific message rational",
            {"minversion": (3, 5), "libversion": {
                "pandas" : {"minversion": "1.0.1", "maxversion": "2.0.1"}, # version could be tuple
                "numpy":  {"minversion": "1.0.1}, #, but that's not what importlib.metadata.version returns
            }},
        ),
    }

• What we do when the lib is not installed (warn the user, or do nothing, I can see both being useful.) For example in pylint-django is django is not installed, then something went very wrong and a fatal error message could be raised !

from pylint.checkers import BaseChecker

class DjangoChecker(BaseChecker):
   # ....
   msgs = {
       #...
       "libversion": {
           "django" : {"onmissing": "fatal"}, # if None nothing is done, if "fatal" a fatal error message is raised.
       }
   }

Let me know what you think about this spec proposal ;)

[mbyrnepr2]

Looks good @Pierre-Sassoulas 👌

[PeterHamfelt]

Hi @mbyrnepr2, @Pierre-Sassoulas ,

I apologize for the delayed response. I've reviewed the suggested setup for specifying library versions and I'm genuinely impressed. The structure you proposed:

"libversion": {
"pandas": {"minversion": "1.0.1", "maxversion": "2.0.1"},
"numpy": {"minversion": "1.0.1"}
}

This approach, especially considering versions as a range (with minimum and maximum bounds), seems both robust and flexible. I believe this could be particularly advantageous for pylint-ml. Given that each checker might depend on specific library versions, and these dependencies are subject to evolve over time, integrating this implementation would significantly enhance the analyzer's adaptability and accuracy.

I'm looking forward to discussing this further and exploring how we can incorporate this feature.

[DanielNoord]

How do we handle non semver versions in dependencies?

[Pierre-Sassoulas]

Good point, we must use string in the data structure not tuple and then handle the complexity internally. Other versioning schemes I know are:

• Date with (month and days ?) + character not in alpha/beta/rc/etc. (hash?) 2022.3.23f1 (unity). This looks almost like proper semver..
• Rounded up date 24.1a1) (black alpha versions), but the actual version have the months (https://github.com/psf/black/releases/tag/23.12.0)
• Improper semver 2.3.1, then 2.4, then 2.4.1(from antique colleague with a perl background, hi Benoit 👋 <3)

We can't use use alphabetical ordering on the string because we need to detect that 9.9.9 is less than 10.0.0, and 2022.9.23f1 is less than 2022.10.23f1 and 24.1a1 is less than 24.9.1 which is less than 24.10.1. I guess it's split on the dot and then try to cast to int. If the versioning scheme does not have separation with dot, then we try to sort it alphabetically. If sorting it alphabetically does not result in something chronological then we don't support it ? Do such schemes exists and do they deserve pylint's checkers 😄 ? (This part is probably going to be fun.)

[DanielNoord]

I think we should utilize something like https://github.com/pypa/packaging.

[Pierre-Sassoulas]

On the one hand, yeah definitely. On the other hand I'd really hate to add a new dependency. Maybe we can live with supporting only semver or semver adjacent.

[mbyrnepr2]

Maybe this doesn't address your concern Pierre but maybe it could be added as an extra dependency since users of Pylint itself wouldn't need it; whereas the plug-in dependency on Pylint would be pylint[packaging].
( Similar to Celery in the way that if you need a redis task queue you would install as celery[redis].)

[PeterHamfelt]

On the one hand, yeah definitely. On the other hand I'd really hate to add a new dependency. Maybe we can live with supporting only semver or semver adjacent.

If pylint does not support lib-version dependency, what would be the recommended approach to handle this locally for pylint plugins?

[Pierre-Sassoulas]

it could be added as an extra dependency

If we add it as an extra, we'll still have to deal with all the issue associated with a new dependency (for dill we had to track an issue for months, then Daniel had to create our own version of dill so we can release pylint in time for python 3.12). My main concern is the maintenance cost and the bloat. The complexity seems high even if we only take what we need and vendor it in pylint : https://github.com/pypa/packaging/blob/32deafe8668a2130a3366b98154914d188f3718e/src/packaging/version.py#L117-L146 / https://github.com/pypa/packaging/blob/32deafe8668a2130a3366b98154914d188f3718e/src/packaging/version.py#L200-L202

What do you mean by "lib-version dependency" @PeterHamfelt ?