We do support Python. Here's an example of a Python scan:
https://lift.sonatype.com/result/smagill-lift-demo/posthog/0...
That gives an idea of the sorts of results we flag in Python code, though we don't expect people to interact with that full bug list often. Recommended usage is to enable Lift on a repo and use the pull request integration so you can focus on results related to code changes as they come in.
We provide deeper analysis and can surface things like thread safety issues and resource leaks. We also focus very closely on ensuring our tools have low false positive rates and so we tend to have less noisy output. This is especially important when you're using the pull request integration (you don't want a bunch of noise in code review).
We closely monitor the "fix rate" -- what percentage of issues reported by Lift are ultimately fixed by developers. If the fix rate for a particular tool or type of rule is too low, then we modify how we configure and run the tool to eliminate the false positives we're seeing. It's very much like what Google reports doing internally in their use of ErrorProne (where they require all rules to have a 90%+ fix rate).
12 comments
[ 2.8 ms ] story [ 33.4 ms ] threadGoing up one directory and searching for Sonatype surfaces https://github.com/marketplace/muse-dev which says "Muse is now Sonatype Lift!"
---
I do battle with my own company around this stuff all the time -- did not one developer click on that link during such a massive marketing push?
What kind of things does lift do to ensure lower false positives?
Is this a pre-trained thing or something that is done custom per repository?