Quantcast

[sonar-dev] Next version of Sonar Python Plugin

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[sonar-dev] Next version of Sonar Python Plugin

Evgeny Mandrikov
Hi all,

I'm pleased to announce that SonarSource wants to boost development of the Sonar Python Plugin and make it first class along with Java, C#, JavaScript.

As for any other language plugin, targets are :
  • reduce dependencies on third-party tools to simplify usage
  • increase quantity and quality of checks
  • improve computation of metrics
And as usual first brick to achieve those targets - implementation of own Python parser with help of SSLR ( https://github.com/SonarSource/sslr ).

Should be noted that Python language has some changes from version to version. E.g. there is removal of some deprecated grammar constructs in 3.2. Of course parser for Sonar should be able to handle all language versions, however as a first baby-step makes sence to choose most stable and popular version, which is 2.7.3.

And during last weekend I spent some time to provide such parser and use it to compute metrics. Parser was tested on Django, Buildbot, Tornado, GNU Mailman.

This is not a call for vote, but a request of feedback :
  • You can take a look on list of solved tickets in Jira ( http://jira.codehaus.org/browse/SONARPLUGINS/fixforversion/18636 ) , and vote for tickets (or even propose your own, e.g. new checks) which not yet part of roadmap for next version - we will pick up most voted for implementation ;)
  • You can test latest snapshot version on your projects by downloading it and installing from Cloudbees ( sonar-python-plugin-0.2-SNAPSHOT.jar ) and inform us about errors during parse, if any, or about any other problems.
Cheers !


--
Evgeny MANDRIKOV | SonarSource
http://sonarsource.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Next version of Sonar Python Plugin

Waleri Enns
On 07/02/2012 01:37 PM, Evgeny Mandrikov wrote:
> Hi all,
Hi,

>
> I'm pleased to announce that SonarSource wants to boost development of
> the Sonar Python Plugin and make it first class along with Java, C#,
> JavaScript.

thanks for caring about Python on Sonar. Some comments below.

>
> As for any other language plugin, targets are :
>
>   * reduce dependencies on third-party tools to simplify usage

Lets be more precise here. As of now, we depend on
- pylint (+Python)
- pygenie (+Python). This is a 'hidden' dependency, as the script is
packaged with the plugin.

While the latter definitely should go (its not the most natural way to
compute McCabe complexity once you have lexer/parser infrastructure, and
it has a couple of issues on its own) the case of the former is not as
clear.

I think pylint is of value for us as it is stable, actively maintained,
feature rich and widely used. On the other hand its an external
dependency and quite slow. So I think the right way is to have both
Checkers (pylint and the own, SSLR-based one) available and see how it
goes. Choosing the checker is easy: just enable/disable according rules
and the right checker will run, i.e.: if you dont wanna have slow pylint
runs, just disable all pylint rules.

There are also three other static checkers worth mentioning (but not
integrated yet):
- pychecker: Implements basically a subset of pylint rules, not as
stable and seems to be abandoned -> Probably not worth the effort. That
conforms with your opinion expressed in
http://jira.codehaus.org/browse/SONARPLUGINS-1638

- pyflakes: Also implements a subset of pylint checks but is much
faster. Overall, I tend to say 'no'.

- pep8: Checks for conformance with the coding style described in PEP8.
As this coding style is widely used and the checker is stable and fast,
I tend to say "yes, worth integrating" here.

>   * increase quantity and quality of checks
>   * improve computation of metrics
>
> And as usual first brick to achieve those targets - implementation of
> own Python parser with help of SSLR ( https://github.com/SonarSource/sslr ).

Evgeny, is there documentation for SSLR? How does it compare with Parser
generators such as ANTLR?

>
> Should be noted that Python language has some changes from version to
> version. E.g. there is removal of some deprecated grammar constructs in
> 3.2. Of course parser for Sonar should be able to handle all language
> versions, however as a first baby-step makes sence to choose most stable
> and popular version, which is 2.7.3.

I think its a reasonable choice for the first version. There is not
*that* much 'syntax-churn' in the language, however. Rather the
3.0-Milestone has been used to tackle some deficits at the core, which
caused some bigger waves at the surface :-)

>
> And during last weekend I spent some time to provide such parser and use
> it to compute metrics.

Just curios: how difficult was it to get the indentation/newline stuff
to get right with SSLR?

> Parser was tested on Django
> <https://github.com/django/django>, Buildbot
> <https://github.com/buildbot/buildbot/tree/>, Tornado
> <https://github.com/facebook/tornado>, GNU Mailman
> <https://launchpad.net/mailman>.
>
> This is not a call for vote, but a request of feedback :
>
>   * You can take a look on list of solved tickets in Jira (
>     http://jira.codehaus.org/browse/SONARPLUGINS/fixforversion/18636 ) ,
>     and vote for tickets (or even propose your own, e.g. new checks)
>     which not yet part of roadmap for next version - we will pick up
>     most voted for implementation ;)
>   * You can test latest snapshot version on your projects by downloading
>     it and installing from Cloudbees (
>     sonar-python-plugin-0.2-SNAPSHOT.jar
>     <https://sonarplugins.ci.cloudbees.com/job/python/lastBuild/org.codehaus.sonar-plugins.python$sonar-python-plugin/artifact/org.codehaus.sonar-plugins.python/sonar-python-plugin/0.2-SNAPSHOT/sonar-python-plugin-0.2-SNAPSHOT.jar> ) and
>     inform us about errors during parse, if any, or about any other
>     problems.
>
> Cheers !
>
>
> --
> *Evgeny MANDRIKOV* | *SonarSource*
> http://sonarsource.com <http://sonarsource.com/>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Next version of Sonar Python Plugin

Evgeny Mandrikov
Hi Waleri,

See my comments below :

On Tue, Jul 3, 2012 at 2:16 PM, Waleri Enns <[hidden email]> wrote:
On 07/02/2012 01:37 PM, Evgeny Mandrikov wrote:
Hi all,
Hi,



I'm pleased to announce that SonarSource wants to boost development of
the Sonar Python Plugin and make it first class along with Java, C#,
JavaScript.

thanks for caring about Python on Sonar. Some comments below.


As for any other language plugin, targets are :

  * reduce dependencies on third-party tools to simplify usage

Lets be more precise here. As of now, we depend on
- pylint (+Python)
- pygenie (+Python). This is a 'hidden' dependency, as the script is packaged with the plugin.

While the latter definitely should go (its not the most natural way to compute McCabe complexity once you have lexer/parser infrastructure, and it has a couple of issues on its own) the case of the former is not as clear.

pygenie already gone ( http://jira.codehaus.org/browse/SONARPLUGINS-1721 ) but some tuning of computation of complexity still needs to be done - see PythonAstScanner.java
 
I think pylint is of value for us as it is stable, actively maintained, feature rich and widely used. On the other hand its an external dependency and quite slow. So I think the right way is to have both Checkers (pylint and the own, SSLR-based one) available and see how it goes. Choosing the checker is easy: just enable/disable according rules and the right checker will run, i.e.: if you dont wanna have slow pylint runs, just disable all pylint rules.

I can also add that integration with pylint ( external tool execution + result parser ) not reliable as shown by SONARPLUGINS-1691
So indeed : in short-term we should keep it, but implement own rules which supposed to be faster and better documented within Sonar ;) and in long term - completely get rid of pylint.
 
There are also three other static checkers worth mentioning (but not integrated yet):
- pychecker: Implements basically a subset of pylint rules, not as stable and seems to be abandoned -> Probably not worth the effort. That conforms with your opinion expressed in
http://jira.codehaus.org/browse/SONARPLUGINS-1638

- pyflakes: Also implements a subset of pylint checks but is much faster. Overall, I tend to say 'no'.

- pep8: Checks for conformance with the coding style described in PEP8. As this coding style is widely used and the checker is stable and fast, I tend to say "yes, worth integrating" here.

My opinion is following :
NO for any third-party tool, because 
  • they add layers of unnecessary complexity and points of failures
  • they complicate configuration of environment : even if hard to imagine development on Python without Python, I can imagine Sonar analysis on machine without Python, moreover additional configuration might be required for tool, whereas would be better to just go to Sonar and enable/disable rules
  • they increase maintenance costs : very painful to keep rules in sync with good descriptions ( this statement based on experience with FindBugs, Checksyle, PMD, ... )
Statements above are based on my expirience with FindBugs, Checksyle, PMD, FlexPMD, CodeNarc, CppCheck, ...

YES for implementation of own rules, which will fully cover well-known practices like PEP8.
 
  * increase quantity and quality of checks
  * improve computation of metrics


And as usual first brick to achieve those targets - implementation of
own Python parser with help of SSLR ( https://github.com/SonarSource/sslr ).

Evgeny, is there documentation for SSLR? How does it compare with Parser generators such as ANTLR?

Not so much documentation for the moment, but we working on improvement of this situation. In few words difference with ANTLR : http://docs.codehaus.org/display/SONAR/SSLR
 

Should be noted that Python language has some changes from version to
version. E.g. there is removal of some deprecated grammar constructs in
3.2. Of course parser for Sonar should be able to handle all language
versions, however as a first baby-step makes sence to choose most stable
and popular version, which is 2.7.3.

I think its a reasonable choice for the first version. There is not *that* much 'syntax-churn' in the language, however. Rather the 3.0-Milestone has been used to tackle some deficits at the core, which caused some bigger waves at the surface :-)

I know that changes are minimal and well-documented, but we need to start from something and do "baby-steps" ( (tm) Freddy Mallet ).
And to be honest : my first attempt (in Saturday) was to implement grammar for 3.2, but then I found that such parser not able to parse almost all existing code from projects known to me, so I downgraded it to 2.7.3
2.7.3 is indeed a good choice, but of course we should continue and cover 3.2 too.
 

And during last weekend I spent some time to provide such parser and use
it to compute metrics.

Just curios: how difficult was it to get the indentation/newline stuff to get right with SSLR?

Hard to say exactly. All work took less than 2 days. If try to make drill down, then let's say that first implementation of lexer (basic support of indent/dedent/newline) took less than 1 hour. And then was tuned according to documentation and real-world projects.
 
Parser was tested on Django
<https://github.com/django/django>, Buildbot
<https://github.com/buildbot/buildbot/tree/>, Tornado
<https://github.com/facebook/tornado>, GNU Mailman
<https://launchpad.net/mailman>.


This is not a call for vote, but a request of feedback :

  * You can take a look on list of solved tickets in Jira (

    http://jira.codehaus.org/browse/SONARPLUGINS/fixforversion/18636 ) ,
    and vote for tickets (or even propose your own, e.g. new checks)
    which not yet part of roadmap for next version - we will pick up
    most voted for implementation ;)
  * You can test latest snapshot version on your projects by downloading

    it and installing from Cloudbees (
    sonar-python-plugin-0.2-SNAPSHOT.jar
    <https://sonarplugins.ci.cloudbees.com/job/python/lastBuild/org.codehaus.sonar-plugins.python$sonar-python-plugin/artifact/org.codehaus.sonar-plugins.python/sonar-python-plugin/0.2-SNAPSHOT/sonar-python-plugin-0.2-SNAPSHOT.jar> ) and

    inform us about errors during parse, if any, or about any other
    problems.

Cheers !


--
*Evgeny MANDRIKOV* | *SonarSource*
http://sonarsource.com <http://sonarsource.com/>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
Best regards,
Evgeny Mandrikov aka Godin <http://godin.net.ru>
http://twitter.com/_godin_
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Next version of Sonar Python Plugin

Waleri Enns
On 07/03/2012 10:50 AM, Evgeny Mandrikov wrote:

> Hi Waleri,
>
> See my comments below :
>
> On Tue, Jul 3, 2012 at 2:16 PM, Waleri Enns <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 07/02/2012 01:37 PM, Evgeny Mandrikov wrote:
>
>         Hi all,
>
>     Hi,
>
>
>
>         I'm pleased to announce that SonarSource wants to boost
>         development of
>         the Sonar Python Plugin and make it first class along with Java, C#,
>         JavaScript.
>
>
>     thanks for caring about Python on Sonar. Some comments below.
>
>
>         As for any other language plugin, targets are :
>
>            * reduce dependencies on third-party tools to simplify usage
>
>
>     Lets be more precise here. As of now, we depend on
>     - pylint (+Python)
>     - pygenie (+Python). This is a 'hidden' dependency, as the script is
>     packaged with the plugin.
>
>     While the latter definitely should go (its not the most natural way
>     to compute McCabe complexity once you have lexer/parser
>     infrastructure, and it has a couple of issues on its own) the case
>     of the former is not as clear.
>
>
> pygenie already gone (
> http://jira.codehaus.org/browse/SONARPLUGINS-1721 ) but some tuning of
> computation of complexity still needs to be done - see
> PythonAstScanner.java
> <https://github.com/SonarCommunity/sonar-python/blob/master/python-squid/src/main/java/org/sonar/python/PythonAstScanner.java#L139>
>
>     I think pylint is of value for us as it is stable, actively
>     maintained, feature rich and widely used. On the other hand its an
>     external dependency and quite slow. So I think the right way is to
>     have both Checkers (pylint and the own, SSLR-based one) available
>     and see how it goes. Choosing the checker is easy: just
>     enable/disable according rules and the right checker will run, i.e.:
>     if you dont wanna have slow pylint runs, just disable all pylint rules.
>
>
> I can also add that integration with pylint ( external tool execution +
> result parser ) not reliable as shown by SONARPLUGINS-1691
> <http://jira.codehaus.org/browse/SONARPLUGINS-1691>\
Yes, but thats not a big issue, to be honest ;)

> So indeed : in short-term we should keep it, but implement own
> rules which supposed to be faster and better documented within Sonar
> ;) and in long term - completely get rid of pylint.
>
>     There are also three other static checkers worth mentioning (but not
>     integrated yet):
>     - pychecker: Implements basically a subset of pylint rules, not as
>     stable and seems to be abandoned -> Probably not worth the effort.
>     That conforms with your opinion expressed in
>     http://jira.codehaus.org/__browse/SONARPLUGINS-1638
>     <http://jira.codehaus.org/browse/SONARPLUGINS-1638>
>
>     - pyflakes: Also implements a subset of pylint checks but is much
>     faster. Overall, I tend to say 'no'.
>
>     - pep8: Checks for conformance with the coding style described in
>     PEP8. As this coding style is widely used and the checker is stable
>     and fast, I tend to say "yes, worth integrating" here.
>
>
> My opinion is following :
> NO for any third-party tool, because
>
>   * they add layers of unnecessary complexity and points of failures
>   * they complicate configuration of environment : even if hard to
>     imagine development on Python without Python, I can imagine Sonar
>     analysis on machine without Python, moreover additional
>     configuration might be required for tool, whereas would be better to
>     just go to Sonar and enable/disable rules
>   * they increase maintenance costs : very painful to keep rules in sync
>     with good descriptions ( this statement based on experience with
>     FindBugs, Checksyle, PMD, ... )
>
> Statements above are based on my expirience with FindBugs, Checksyle,
> PMD, FlexPMD, CodeNarc, CppCheck, ...
>
> YES for implementation of own rules, which will fully cover well-known
> practices like PEP8.

You name valid points, but to my opinion, we shoudnt forget the other
side, too. First of all, the reimplementation of static code checking
tools is obviously not cost-free: you need X time to catch up and after
this, keeping up with others (to be competitive) will cause costs too.

Second, I find the new SSLR based checker to be less accessible: ideally
a tool is usable from the command line, from an (extensible) text
editor, from sonar, etc. That the case with a CLI checker like pylint
but not with our new implementation (or do I miss something?).

Third, were duplicating efforts.

So, IMO, the "lets reimplement all ourselves" is not always the winning
strategy ;) its a case by case decision.

Having said this, I'm not entirely sure which one is best in the case of
pep8. Its only a tendency.

>
>            * increase quantity and quality of checks
>            * improve computation of metrics
>
>
>         And as usual first brick to achieve those targets -
>         implementation of
>         own Python parser with help of SSLR (
>         https://github.com/__SonarSource/sslr
>         <https://github.com/SonarSource/sslr> ).
>
>
>     Evgeny, is there documentation for SSLR? How does it compare with
>     Parser generators such as ANTLR?
>
>
> Not so much documentation for the moment, but we working on improvement
> of this situation. In few words difference with ANTLR :
> http://docs.codehaus.org/display/SONAR/SSLR
>
>
>         Should be noted that Python language has some changes from
>         version to
>         version. E.g. there is removal of some deprecated grammar
>         constructs in
>         3.2. Of course parser for Sonar should be able to handle all
>         language
>         versions, however as a first baby-step makes sence to choose
>         most stable
>         and popular version, which is 2.7.3.
>
>
>     I think its a reasonable choice for the first version. There is not
>     *that* much 'syntax-churn' in the language, however. Rather the
>     3.0-Milestone has been used to tackle some deficits at the core,
>     which caused some bigger waves at the surface :-)
>
>
> I know that changes are minimal and well-documented, but we need to
> start from something and do "baby-steps" ( (tm) Freddy Mallet ).
> And to be honest : my first attempt (in Saturday) was to implement
> grammar for 3.2, but then I found that such parser not able to parse
> almost all existing code from projects known to me, so I downgraded it
> to 2.7.3
> 2.7.3 is indeed a good choice, but of course we should continue and
> cover 3.2 too.
>
>
>         And during last weekend I spent some time to provide such parser
>         and use
>         it to compute metrics.
>
>
>     Just curios: how difficult was it to get the indentation/newline
>     stuff to get right with SSLR?
>
>
> Hard to say exactly. All work took less than 2 days. If try to make
> drill down, then let's say that first implementation of lexer (basic
> support of indent/dedent/newline) took less than 1 hour. And then was
> tuned according to documentation and real-world projects.
>
>         Parser was tested on Django
>         <https://github.com/django/__django
>         <https://github.com/django/django>>, Buildbot
>         <https://github.com/buildbot/__buildbot/tree/
>         <https://github.com/buildbot/buildbot/tree/>>, Tornado
>         <https://github.com/facebook/__tornado
>         <https://github.com/facebook/tornado>>, GNU Mailman
>         <https://launchpad.net/mailman__>.
>
>
>         This is not a call for vote, but a request of feedback :
>
>            * You can take a look on list of solved tickets in Jira (
>
>         http://jira.codehaus.org/__browse/SONARPLUGINS/__fixforversion/18636
>         <http://jira.codehaus.org/browse/SONARPLUGINS/fixforversion/18636>
>         ) ,
>              and vote for tickets (or even propose your own, e.g. new
>         checks)
>              which not yet part of roadmap for next version - we will
>         pick up
>              most voted for implementation ;)
>            * You can test latest snapshot version on your projects by
>         downloading
>
>              it and installing from Cloudbees (
>              sonar-python-plugin-0.2-__SNAPSHOT.jar
>         <https://sonarplugins.ci.__cloudbees.com/job/python/__lastBuild/org.codehaus.sonar-__plugins.python$sonar-python-__plugin/artifact/org.codehaus.__sonar-plugins.python/sonar-__python-plugin/0.2-SNAPSHOT/__sonar-python-plugin-0.2-__SNAPSHOT.jar
>         <https://sonarplugins.ci.cloudbees.com/job/python/lastBuild/org.codehaus.sonar-plugins.python$sonar-python-plugin/artifact/org.codehaus.sonar-plugins.python/sonar-python-plugin/0.2-SNAPSHOT/sonar-python-plugin-0.2-SNAPSHOT.jar>>
>         ) and
>
>              inform us about errors during parse, if any, or about any other
>              problems.
>
>         Cheers !
>
>
>         --
>         *Evgeny MANDRIKOV* | *SonarSource*
>         http://sonarsource.com <http://sonarsource.com/>
>
>
>
>     ------------------------------__------------------------------__---------
>     To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/__manage_email
>     <http://xircles.codehaus.org/manage_email>
>
>
>
>
>
> --
> Best regards,
> Evgeny Mandrikov aka Godin <http://godin.net.ru>
> http://twitter.com/_godin_


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Next version of Sonar Python Plugin

Evgeny Mandrikov
 
You name valid points, but to my opinion, we shoudnt forget the other side, too. First of all, the reimplementation of static code checking tools is obviously not cost-free: you need X time to catch up and after this, keeping up with others (to be competitive) will cause costs too.

Why you care, if this will cost zero time for you? ;)
If we talk only about PEP8, then based on list https://github.com/jcrocholl/pep8/wiki/ErrorCodes from my point of view - approximate time to develop own rules is no more than week.

Second, I find the new SSLR based checker to be less accessible: ideally a tool is usable from the command line, from an (extensible) text editor, from sonar, etc. That the case with a CLI checker like pylint but not with our new implementation (or do I miss something?).

I'm not saying that you should stop using command-line tools, but please do not mix Sonar as code quality management platform with command-line tools. And we talk about development of plugin for Sonar, but not about command-line checker.
 
Third, were duplicating efforts.

So, IMO, the "lets reimplement all ourselves" is not always the winning strategy ;) its a case by case decision.

Yes - it's a case by case decision.
Lets simply say that SonarSource will invest time ( as many as it will be required ) into implementation of own checks rather than into integration with third-party tools.
Of course if you want - go on and integrate pep8-checker in plugin.


--
Best regards,
Evgeny Mandrikov aka Godin <http://godin.net.ru>
http://twitter.com/_godin_
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Next version of Sonar Python Plugin

Waleri Enns
On 07/03/2012 02:59 PM, Evgeny Mandrikov wrote:
>     You name valid points, but to my opinion, we shoudnt forget the
>     other side, too. First of all, the reimplementation of static code
>     checking tools is obviously not cost-free: you need X time to catch
>     up and after this, keeping up with others (to be competitive) will
>     cause costs too.
>
>
> Why you care, if this will cost zero time for you? ;)

Well, because I care about this particular piece of software and because
I plan to maintain it.

> If we talk only about PEP8, then based on list
> https://github.com/jcrocholl/pep8/wiki/ErrorCodes from my point of view
> - approximate time to develop own rules is no more than week.

>
>     Second, I find the new SSLR based checker to be less accessible:
>     ideally a tool is usable from the command line, from an (extensible)
>     text editor, from sonar, etc. That the case with a CLI checker like
>     pylint but not with our new implementation (or do I miss something?).
>
>
> I'm not saying that you should stop using command-line tools, but please
> do not mix Sonar as code quality management platform with command-line
> tools. And we talk about development of plugin for Sonar, but not about
> command-line checker.

Its just a comparison of two approaches: implement the check in a
command line tool and make it available in Sonar via a plugin vs.
implement the check directly in a Sonar plugin.

>
>     Third, were duplicating efforts.
>
>     So, IMO, the "lets reimplement all ourselves" is not always the
>     winning strategy ;) its a case by case decision.
>
>
> Yes - it's a case by case decision.
> Lets simply say that SonarSource will invest time ( as many as it will
> be required ) into implementation of own checks rather than into
> integration with third-party tools.
> Of course if you want - go on and integrate pep8-checker in plugin.

Just to be clear: Im not arguing against your work. We just talk 'tech'
and try to develop a common understanding of some general problems. Just
to make sure we're pulling in one direction.

>
>
> --
> Best regards,
> Evgeny Mandrikov aka Godin <http://godin.net.ru>
> http://twitter.com/_godin_


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Next version of Sonar Python Plugin

Freddy Mallet
Hi Waleri,

You're right, each time we cover a new language with a Sonar plugin, there is "almost" a trade-off between re-using some available libraries and developing some new dedicated Sonar analyzers.

In fact when we created the first version of the Sonar platform 5 years ago there wasn't any Sonar source code analyzer. That's always a good option to quickly bootstrap a plugin. But integrating some third party tools has also some big disadvantages on the long term like :
  • Most of the time those third party tools require a dedicated and sometimes tedious installation process
  • Contributing to those third party tools to provide some new rules is not always so easy : due to the language used, due to the community process, due to the underlying parsing technology, ...
  • There is a big set of similar quality rules in all languages but by using third party tools there is no way to leverage this aspect
That's why in the beginning of this year we've decided to open source our own technology SSLR to analyse any kind of source code and to create a dedicated team to provide and maintain some source code analysers based on SSLR. That's what we did or we plan to do on Javascript, on Flex, on C#, on Java (planned for Sonar 3.3), on Python and perhaps one day on PHP, on Dart, on Ruby, ... 

I know that there is almost no documentation available on SSLR (expect the unit tests and all the implementations already available) and I can understand any remarks like : "Guys, do you really hope to do a better job than what has been done with Antlr ?", "Do you really believe that we'll manage to compete with well-known source code analysers like cppcheck, pylint, pmd, ... ?" but indeed that's our plan and this is already partially a reality. In fact SSLR is not just a parsing technology as Antlr is, let's say that SSLR is a source code analysing framework which includes a parsing technology.

This was not the most easy and less risky path, but this is the one we've decided to go on :)

Kind regards,
Freddy
-----
Sonar for Continuous Inspection



On Tue, Jul 3, 2012 at 5:56 PM, Waleri Enns <[hidden email]> wrote:
On 07/03/2012 02:59 PM, Evgeny Mandrikov wrote:
    You name valid points, but to my opinion, we shoudnt forget the
    other side, too. First of all, the reimplementation of static code
    checking tools is obviously not cost-free: you need X time to catch
    up and after this, keeping up with others (to be competitive) will
    cause costs too.


Why you care, if this will cost zero time for you? ;)

Well, because I care about this particular piece of software and because I plan to maintain it.


If we talk only about PEP8, then based on list
https://github.com/jcrocholl/pep8/wiki/ErrorCodes from my point of view
- approximate time to develop own rules is no more than week.


    Second, I find the new SSLR based checker to be less accessible:
    ideally a tool is usable from the command line, from an (extensible)
    text editor, from sonar, etc. That the case with a CLI checker like
    pylint but not with our new implementation (or do I miss something?).


I'm not saying that you should stop using command-line tools, but please
do not mix Sonar as code quality management platform with command-line
tools. And we talk about development of plugin for Sonar, but not about
command-line checker.

Its just a comparison of two approaches: implement the check in a command line tool and make it available in Sonar via a plugin vs. implement the check directly in a Sonar plugin.



    Third, were duplicating efforts.

    So, IMO, the "lets reimplement all ourselves" is not always the
    winning strategy ;) its a case by case decision.


Yes - it's a case by case decision.
Lets simply say that SonarSource will invest time ( as many as it will
be required ) into implementation of own checks rather than into
integration with third-party tools.
Of course if you want - go on and integrate pep8-checker in plugin.

Just to be clear: Im not arguing against your work. We just talk 'tech' and try to develop a common understanding of some general problems. Just to make sure we're pulling in one direction.




--
Best regards,
Evgeny Mandrikov aka Godin <http://godin.net.ru>
http://twitter.com/_godin_


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Next version of Sonar Python Plugin

Waleri Enns
Hi Freddy,

thanks for clarifying of the roadmap. Its an ambitious plan to compete
with a whole set of mature code checkers and I wish you all luck. May
the fittest survive ;)

SSLR (according to Evgeny) makes the job a lot easier, although. All the
more importance has some initial technical documentation for it, such
that guys like me can get more easily into it and help out to realize
the plan.

Cheers,
--
Waleri Enns


On 07/03/2012 09:48 PM, Freddy Mallet wrote:

> Hi Waleri,
>
> You're right, each time we cover a new language with a Sonar plugin,
> there is "almost" a trade-off between re-using some available libraries
> and developing some new dedicated Sonar analyzers.
>
> In fact when we created the first version of the Sonar platform 5 years
> ago there wasn't any Sonar source code analyzer. That's always a good
> option to quickly bootstrap a plugin. But integrating some third party
> tools has also some big disadvantages on the long term like :
>
>   * Most of the time those third party tools require a dedicated and
>     sometimes tedious installation process
>   * Contributing to those third party tools to provide some new rules is
>     not always so easy : due to the language used, due to the community
>     process, due to the underlying parsing technology, ...
>   * There is a big set of similar quality rules in all languages but by
>     using third party tools there is no way to leverage this aspect
>
> That's why in the beginning of this year we've decided to open source
> our own technology SSLR to analyse any kind of source code and to create
> a dedicated team to provide and maintain some source code analysers
> based on SSLR. That's what we did or we plan to do on Javascript, on
> Flex, on C#, on Java (planned for Sonar 3.3), on Python and perhaps one
> day on PHP, on Dart, on Ruby, ...
>
> I know that there is almost no documentation available on SSLR (expect
> the unit tests and all the implementations already available) and I can
> understand any remarks like : "Guys, do you really hope to do a better
> job than what has been done with Antlr ?", "Do you really believe that
> we'll manage to compete with well-known source code analysers like
> cppcheck, pylint, pmd, ... ?" but indeed that's our plan and this is
> already partially a reality. In fact SSLR is not just a parsing
> technology as Antlr is, let's say that SSLR is a source code analysing
> framework which includes a parsing technology.
>
> This was not the most easy and less risky path, but this is the one
> we've decided to go on :)
>
> Kind regards,
> Freddy
> -----
> twitter.com/FreddyMallet <https://twitter.com/FreddyMallet>
> Sonar for Continuous Inspection
>
>
>
> On Tue, Jul 3, 2012 at 5:56 PM, Waleri Enns <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 07/03/2012 02:59 PM, Evgeny Mandrikov wrote:
>
>              You name valid points, but to my opinion, we shoudnt forget the
>              other side, too. First of all, the reimplementation of
>         static code
>              checking tools is obviously not cost-free: you need X time
>         to catch
>              up and after this, keeping up with others (to be
>         competitive) will
>              cause costs too.
>
>
>         Why you care, if this will cost zero time for you? ;)
>
>
>     Well, because I care about this particular piece of software and
>     because I plan to maintain it.
>
>
>         If we talk only about PEP8, then based on list
>         https://github.com/jcrocholl/__pep8/wiki/ErrorCodes
>         <https://github.com/jcrocholl/pep8/wiki/ErrorCodes> from my
>         point of view
>         - approximate time to develop own rules is no more than week.
>
>
>
>              Second, I find the new SSLR based checker to be less
>         accessible:
>              ideally a tool is usable from the command line, from an
>         (extensible)
>              text editor, from sonar, etc. That the case with a CLI
>         checker like
>              pylint but not with our new implementation (or do I miss
>         something?).
>
>
>         I'm not saying that you should stop using command-line tools,
>         but please
>         do not mix Sonar as code quality management platform with
>         command-line
>         tools. And we talk about development of plugin for Sonar, but
>         not about
>         command-line checker.
>
>
>     Its just a comparison of two approaches: implement the check in a
>     command line tool and make it available in Sonar via a plugin vs.
>     implement the check directly in a Sonar plugin.
>
>
>
>              Third, were duplicating efforts.
>
>              So, IMO, the "lets reimplement all ourselves" is not always the
>              winning strategy ;) its a case by case decision.
>
>
>         Yes - it's a case by case decision.
>         Lets simply say that SonarSource will invest time ( as many as
>         it will
>         be required ) into implementation of own checks rather than into
>         integration with third-party tools.
>         Of course if you want - go on and integrate pep8-checker in plugin.
>
>
>     Just to be clear: Im not arguing against your work. We just talk
>     'tech' and try to develop a common understanding of some general
>     problems. Just to make sure we're pulling in one direction.
>
>
>
>
>         --
>         Best regards,
>         Evgeny Mandrikov aka Godin <http://godin.net.ru>
>         http://twitter.com/_godin_
>
>
>
>     ------------------------------__------------------------------__---------
>     To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/__manage_email
>     <http://xircles.codehaus.org/manage_email>
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Next version of Sonar Python Plugin

Tamás Kende
Hi all,

+1 for the technical docs... I would like to check can I use it for Erlang easily or not, but it is really hard if I have to hunt down every piece of info from different repos. At least can you collect the urls of all the implementations and all useful code pieces to one wiki page?

Thanks,

Cheers

Tamas

On Wed, Jul 4, 2012 at 8:05 AM, Waleri Enns <[hidden email]> wrote:
Hi Freddy,

thanks for clarifying of the roadmap. Its an ambitious plan to compete with a whole set of mature code checkers and I wish you all luck. May the fittest survive ;)

SSLR (according to Evgeny) makes the job a lot easier, although. All the more importance has some initial technical documentation for it, such that guys like me can get more easily into it and help out to realize the plan.

Cheers,
--
Waleri Enns



On 07/03/2012 09:48 PM, Freddy Mallet wrote:
Hi Waleri,

You're right, each time we cover a new language with a Sonar plugin,
there is "almost" a trade-off between re-using some available libraries
and developing some new dedicated Sonar analyzers.

In fact when we created the first version of the Sonar platform 5 years
ago there wasn't any Sonar source code analyzer. That's always a good
option to quickly bootstrap a plugin. But integrating some third party
tools has also some big disadvantages on the long term like :

  * Most of the time those third party tools require a dedicated and
    sometimes tedious installation process
  * Contributing to those third party tools to provide some new rules is

    not always so easy : due to the language used, due to the community
    process, due to the underlying parsing technology, ...
  * There is a big set of similar quality rules in all languages but by

    using third party tools there is no way to leverage this aspect

That's why in the beginning of this year we've decided to open source
our own technology SSLR to analyse any kind of source code and to create
a dedicated team to provide and maintain some source code analysers
based on SSLR. That's what we did or we plan to do on Javascript, on
Flex, on C#, on Java (planned for Sonar 3.3), on Python and perhaps one
day on PHP, on Dart, on Ruby, ...

I know that there is almost no documentation available on SSLR (expect
the unit tests and all the implementations already available) and I can
understand any remarks like : "Guys, do you really hope to do a better
job than what has been done with Antlr ?", "Do you really believe that
we'll manage to compete with well-known source code analysers like
cppcheck, pylint, pmd, ... ?" but indeed that's our plan and this is
already partially a reality. In fact SSLR is not just a parsing
technology as Antlr is, let's say that SSLR is a source code analysing
framework which includes a parsing technology.

This was not the most easy and less risky path, but this is the one
we've decided to go on :)

Kind regards,
Freddy
-----
twitter.com/FreddyMallet <https://twitter.com/FreddyMallet>

Sonar for Continuous Inspection



On Tue, Jul 3, 2012 at 5:56 PM, Waleri Enns <[hidden email]
<mailto:[hidden email]>> wrote:

    On 07/03/2012 02:59 PM, Evgeny Mandrikov wrote:

             You name valid points, but to my opinion, we shoudnt forget the
             other side, too. First of all, the reimplementation of
        static code
             checking tools is obviously not cost-free: you need X time
        to catch
             up and after this, keeping up with others (to be
        competitive) will
             cause costs too.


        Why you care, if this will cost zero time for you? ;)


    Well, because I care about this particular piece of software and
    because I plan to maintain it.


        If we talk only about PEP8, then based on list
        https://github.com/jcrocholl/__pep8/wiki/ErrorCodes

        <https://github.com/jcrocholl/pep8/wiki/ErrorCodes> from my
        point of view
        - approximate time to develop own rules is no more than week.



             Second, I find the new SSLR based checker to be less
        accessible:
             ideally a tool is usable from the command line, from an
        (extensible)
             text editor, from sonar, etc. That the case with a CLI
        checker like
             pylint but not with our new implementation (or do I miss
        something?).


        I'm not saying that you should stop using command-line tools,
        but please
        do not mix Sonar as code quality management platform with
        command-line
        tools. And we talk about development of plugin for Sonar, but
        not about
        command-line checker.


    Its just a comparison of two approaches: implement the check in a
    command line tool and make it available in Sonar via a plugin vs.
    implement the check directly in a Sonar plugin.



             Third, were duplicating efforts.

             So, IMO, the "lets reimplement all ourselves" is not always the
             winning strategy ;) its a case by case decision.


        Yes - it's a case by case decision.
        Lets simply say that SonarSource will invest time ( as many as
        it will
        be required ) into implementation of own checks rather than into
        integration with third-party tools.
        Of course if you want - go on and integrate pep8-checker in plugin.


    Just to be clear: Im not arguing against your work. We just talk
    'tech' and try to develop a common understanding of some general
    problems. Just to make sure we're pulling in one direction.




        --
        Best regards,
        Evgeny Mandrikov aka Godin <http://godin.net.ru>
        http://twitter.com/_godin_



    ------------------------------__------------------------------__---------

    To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/__manage_email
    <http://xircles.codehaus.org/manage_email>





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Loading...