adding a minimal lgtm.yml file

[fchapoton]

This will tell LGTM to use Python3 during its code analysis.

as suggested here:

https://lgtm.com/help/lgtm/analysis-faqs#how-python-version-identified

CC: @tscrim @kiwifb @embray @vbraun

Component: scripts

Author: Frédéric Chapoton

Branch/Commit: f3640c2

Reviewer: Erik Bray

Issue created by migration from https://trac.sagemath.org/ticket/28839

[fchapoton]

Branch: u/chapoton/28839

[fchapoton]

New commits:

d6728ff

adding a .lgtm.yml file to specify the python version

[fchapoton]

Commit: d6728ff

[fchapoton]

Description changed:

--- 
+++ 
@@ -1,3 +1,5 @@
 This will tell LGTM to use Python3 during its code analysis.
 
+as suggested here:
 
+https://lgtm.com/help/lgtm/analysis-faqs#how-python-version-identified

[kiwifb]

comment:3

That looks interesting.

[fchapoton]

comment:4

The reports can be found here:

https://lgtm.com/projects/g/sagemath/sage/?mode=list

but the problem is that it only runs when "master" branch is updated..

[embray]

comment:5

I wonder if there is a setting to change the branch to track.

[fchapoton]

comment:6

the only way seems to be : change our main branch on github to be "develop"

[embray]

comment:7

Replying to @embray:

I wonder if there is a setting to change the branch to track.

ISTM that LGTM is reading from the GitHub mirror of our repo, so I just need to change its default branch to the develop branch. I don't think there will be any consequences to doing so, so I'll go ahead and do that.

[embray]

comment:8

I'm looking at this site, and while many of the alerts look useful, a great many of the "errors" reported are due to supposedly incorrect arguments to a class's __init__, except their analysis is not clever enough to consider classes which have a metaclass with a custom __call__ (e.g. our ClasscallMetaclass which is used all over the place).

So perhaps while we're adding this file it might be helpful to globally exclude this and related errors as explained here. For example, from what I'm seeing in the errors, we want at least:

queries:
    - exclude: py/call/wrong-named-class-argument
    - exclude: py/call/wrong-number-class-arguments

Of course, we can also suppress alerts on individual lines, but these two are so pervasive it would not be practical. Suppressing them globally unfortunately could hide legitimate errors, though these errors are likely to be caught by tests in most cases.