scapegoat duplicates scala/scala-abide? about scapegoat HOT 21 CLOSED

The scala-abide project hasn't seen a commit in 3 years now. Also I am not sure if the private communication between the involved maintainers reached any consensus, but I'd risk a guess nothing is happening in the area.

Thus let me close the issue. If any new plans for cooperation are shared, we can obviously reconsider.

from scapegoat.

Interesting. Doesn't look like they've done a lot on it though, 33 commits
and 6 rules. Same basic idea and almost identical "rule structure". I could
port the scapegoat rules very easily.

I don't think anyone wants to adapt Findbugs because once you delve into it
you realize most of the warnings are just not applicable to Scala (the main
exception being math related things - bitwise ops etc), and the things you
really want to be warned about you need to plug into the compiler to do.

On 14 August 2014 14:27, Richard Bradley [email protected] wrote:

It looks like Scala-core have recently come up with the same idea as
scapegoat and are busy implementing their own scalac plugin that also
duplicates Findbugs: https://github.com/scala/scala-abide

It might be worth hacking on that instead, as it's likely to capture
scapegoat's mindshare / user base, since it is backed by the core scala
team.

(No-one else seems interested in adapting Findbugs for Scala; everyone
seems to want to reinvent the wheel. Maybe I'll moan about that on the
Scala mailing list.)

—
Reply to this email directly or view it on GitHub
#38.

from scapegoat.

I don't think anyone wants to adapt Findbugs because once you delve into it
you realize most of the warnings are just not applicable to Scala

I disagree (things like leaked file descriptors, incorrect use of the Java stdlibs, etc. etc. etc.), but I can see that I'll have to demonstrate this rather than just argue for it :-)

Doesn't look like they've done a lot on it though,

Yes, not much yet. There hasn't been an announcement on the Scala mailing list either. I have emailed a couple of Typesafe people to alert them to the duplication, but they might want to go their own way. I think they have a few people full time on Scala stuff so I'd expect Abide to catch up / overtake scapegoat before too long.

from scapegoat.

I made a list of all findbugs inspections and marked them as included, exclude or maybe, and seriously a majority of them were a waste of time, mostly because in Scala land we don't use the libraries they're targeting. Even things like all the clone rules (at least 10) are mostly irrelevant as we all use case classes and copy.

If they even have someone part time on abide it wouldn't take long to overtake scapegoat, since scapegoat is a community project with 1 contributor atm :) But I've got nearly 100 inspections now, from 12 last month.

from scapegoat.

I recommend giving them some healthy competition, but right now 'competition' is very generous because you are streets ahead of them in terms of number of inspections. Don't fold so easily !

from scapegoat.

@sksamuel We're hoping that abide will be a great place to contribute rules (or even to write project-specific rules). We're haven't launched it yet because we want to flesh out the APIs a bit further.

I'm also aware that rules are currently difficult or impossible to write without modifying the compiler. (e.g. replicating -Xlint:infer-any). I'd like to add the necessary hooks into type inference / checking to let us move all the lint rules out to abide.

But we welcome any contributions even at this stage, and would love to chat to you about your experiences in writing scapegoat, and whether we can join forces. Looks like you have made amazing progress here!

/cc @dragos @adriaanm

from scapegoat.

In particular, we're keen to show best practices for writing post-typer rules, comparing types and symbols.

I notice that a few of your rules exhibit a few common fragilities that I've also noticed when reviewing similar tools.

So I'd like to see diffs like:

- case TypeTree() if tree.tpe.erasure.toString() == "Traversable[Any]" => warn(tree)
+ case TypeTree() if tree.tpe.typeSymbol == typeOf[Traversable[_]].typeSymbol => warn(tree) 

Or moving checks like ImpossibleOptionSizeCondition to a post-typer one, rather than relying on a particular syntactic match.

from scapegoat.

To elaborate on @retronym's comment, we see Typesafe's role in the development of abide as providing a friendly platform for others to develop style checking rules.

We don't intend to compete on how many the rules we offer (we don't have the resources for that, the small Scala team at Typesafe is quite busy with implementing Java 8 support), but instead hope you will decide to use the abide platform to develop your style checking rules.

We will keep abide in synch with the Scala compiler, so you can focus on adding and refining the actual rules.

from scapegoat.

Definitely one of the goals of abide is to consolidate Scala linting tools. There are a number of compiler plugins already (linter and wart remover among others) that do very similar things. By creating abide we hope to provide a commonplace for contributing such rules, together with infrastructure such as sbt/maven/IDE integration and error reporting.

I'd love to chat more about ways to unite efforts in this area!

from scapegoat.

Hi all,

So are you saying you want me to port scapegoat rules to abide's framework. But do you want scapegoat to remain as a "set of rules you can download and plug into abide" or "port them to abide's repo"

from scapegoat.

Both are possible. It's early days for us, so we're figuring this out together :-)
I've been away for a while, so I'll let @dragos confirm, but I believe abide supports loading rules from jars, so you can develop them in your own repo, publish them and have your users activate them by adding a libraryDependency in sbt (or the equivalent if you're running abide outside of sbt).

from scapegoat.

Indeed. Abide rules are distributed in the same way, so in a sense there is no "built-in" rule. All you need to do is to add a dependency in the "abide" configuration, et voilà, the new rules are taken into consideration:

libraryDependencies += "com.typesafe" %% "abide-core" % "0.1-SNAPSHOT" % "abide"

However, I have a slight preference for contributing general-purpose rules to abide-core, so we don't end up duplicating too many rules.

from scapegoat.

Ok so how do you want to proceed.
On 3 Oct 2014 09:48, "Iulian Dragos" [email protected] wrote:

Indeed. Abide rules are distributed in the same way, so in a sense there
is no "built-in" rule. All you need to do is to add a dependency in the
"abide" configuration, et voilà, the new rules are taken into consideration:

libraryDependencies += "com.typesafe" %% "abide-core" % "0.1-SNAPSHOT" % "abide"

However, I have a slight preference for contributing general-purpose rules
to abide-core, so we don't end up duplicating too many rules.

—
Reply to this email directly or view it on GitHub
#38 (comment)
.

from scapegoat.

So did you guys want to discuss this....?

from scapegoat.

I apologize. I thought we had answered your question at least at a meta-level: we're open to whatever you prefer :-) These are very early days for abide, which (to be honest) is being run as a side project internally (for now).

from scapegoat.

Have a look at scala/scala-abide#5 for an example of how to add rules to the main rep.

from scapegoat.

@sksamuel I think most of the rules are general enough to go to abide-core. I think it would be great to contribute a few. We'd get some feedback on how the API works.

from scapegoat.

@dragos nice to meet you at ScalaExchange. So after our chat, in summary, do you want me to a) PR rules and you can merge them into abide core, or b) keep them here but just make them use abide's framework. PS are you going to come up with a better name than abide ;)

from scapegoat.

Obviously the Abide should be renamed 'abiding-goat'! - If I had a vote (which I accept I probably dont) I would think abide should be renamed to scapegoat.

from scapegoat.

@sksamuel it was great meeting you too!

How about we start with a few rules that would go in scala/scala-abide? I'd pick a few that make sense for everyone (to place in "core"):

• CollectionPromotionToAny
• ComparisonToEmptyList/set
• Filter.head

Then, I think it would be excellent to have a scapegoat-rules package for abide, that is hosted here. WDYT?

from scapegoat.

Ok sounds good, I'll email you privately if (when) I get stuck.

On 10 December 2014 at 16:37, Iulian Dragos [email protected]
wrote:

@sksamuel https://github.com/sksamuel it was great meeting you too!

How about we start with a few rules that would go in scala/scala-abide?
I'd pick a few that make sense for everyone (to place in "core"):

• CollectionPromotionToAny
• ComparisonToEmptyList/set
• Filter.head

Then, I think it would be excellent to have a scapegoat-rules package for
abide, that is hosted here. WDYT?

—
Reply to this email directly or view it on GitHub
#38 (comment)
.

from scapegoat.