-
Notifications
You must be signed in to change notification settings - Fork 21
Improve my car... ehh... sbt #16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not agree with all the changes. To me it seems that the build got more complicated than it was before and the benefits are not obvious. I am also afraid of false positives in the linters etc. Anyway, please update the PR and we'll see.
build.sbt
Outdated
"-P:silencer:checkUnused" | ||
), | ||
scalacOptions --= { | ||
if (!sys.env.contains("TRAVIS")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why? I'd like to keep the build as clean as possible from such ifs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's worth failing warnings only on CI, because locally fatal warnings
doesn't work well with scalafix
, eg https://scalacenter.github.io/scalafix/docs/rules/RemoveUnused.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And this is exactly what I was talking about! The linters are not mature in my opinion because they have these limitations I don't like. I want my build to fail on warnings locally the same way it fails in CI. It's not acceptable for me to have it behave differently. I'd rather get rid of scalafix than this, sorry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what you really want it linters to only warn locally (because it's very annoying if you have some work-in-progress and it fails because of unused import), but also have an easy way how to turn them fatal.
example/src/main/scala/com/avast/server/toolkit/example/Main.scala
Outdated
Show resolved
Hide resolved
# Conflicts: # build.sbt # example/src/main/scala/com/avast/server/toolkit/example/Main.scala # project/Dependencies.scala
@jakubjanecek build is green, ready to merge from my POV. we can talk about details in person tomorrow if you want |
example/lock.sbt
Outdated
// DON'T EDIT THIS FILE. | ||
// This file is auto generated by sbt-lock 0.6.1. | ||
// https://github.com/tkawachi/sbt-lock/ | ||
dependencyOverrides ++= { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't like this at all - what problem does it solve?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also think right now we are not in a state where we would need this. We can always add it but I'd like to remove it for now too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's not worry about lock
right now. removed.
@@ -35,6 +35,7 @@ object ConfigurableThreadFactory { | |||
/** | |||
* @param nameFormat Formatted with long number, e.g. my-thread-%02d | |||
*/ | |||
@SuppressWarnings(Array("org.wartremover.warts.DefaultArguments")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why are we calling DefaultArguments wart? if it's a wart, why are we using it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sideeffffect Can you explain the wart? I am using default arguments on purpose and having to suppress it everywhere in my code seems very strange, I'd rather remove the wart.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
default arguments are frowned upon in the FP community, I personally avoid them too
see https://blog.ssanj.net/posts/2019-05-01-why-are-default-parameter-values-considered-bad-in-scala.html
but this wart applies also to constructors too, which is a big part of PureConfig functionality
so I'm disabling the wart
@hanny24 @augi Inviting you to the discussion because there seems to be quite big disagreement on how build should look. I am interested in your opinion on the setup of linters (scalafix, wart remover) and use of extra compiler plugins (silencer) My view is that for now it seems to just complicate the build and the code (forcing us to suppress warnings where we shouldn't have) and it does not give us much now - it would protect us probably from some trouble in the future but now I think I am a better linter myself :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, it's strange to me to have so much infrastructure code to setup this relatively simple project.
project/Dependencies.scala
Outdated
val zioInteropCats = "dev.zio" %% "zio-interop-cats" % "2.0.0.0-RC4" | ||
object Versions { | ||
val catsEffect = "2.0.0" | ||
val kindProjector = "0.10.3" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm just curious if Scala Steward would be OK with this style.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is - see here: https://github.com/avast/datadog4s/pull/43/files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this needs to work with Steward, good point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the point is that the versions are now refactored into separate Version
object and I would be afraid it does not work that way...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah that might be a problem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
example/src/main/scala/com/avast/server/toolkit/example/Main.scala
Outdated
Show resolved
Hide resolved
@@ -4,6 +4,7 @@ import java.util.concurrent.TimeUnit | |||
|
|||
import scala.concurrent.duration.{Duration, FiniteDuration} | |||
|
|||
@SuppressWarnings(Array("org.wartremover.warts.DefaultArguments")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We definitely want to remove this wart.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that this PR combines many things into one which makes it very difficult to argue about. I think it's very premature to use sbt lock right now. It will just complicate things right now. But it might be useful once we reach 1.0 version.
On the other hand scalafix might be useful right away. I would just be very careful about the rules that we use. What I would start with right now is some sort of rule that makes sure the imports are properly organized.
@sideeffffect I think @hanny24 is right about the fact that by redoing the whole build it triggered a lot of alarms. I know you have put a lot of work into this and you mean it well however as you can see different people have different opinions so as a whole I don't think we can merge this. I suggest we close this PR and try to add some of the things one by one so that we can digest it slowly. The things I think can be done are the following:
And that's it. Let's start with this and we'll update in the future according to our needs. What do you say? |
# Conflicts: # build.sbt # project/Dependencies.scala
* no lock * default arguments allowed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
implemented the requested changes
example/lock.sbt
Outdated
// DON'T EDIT THIS FILE. | ||
// This file is auto generated by sbt-lock 0.6.1. | ||
// https://github.com/tkawachi/sbt-lock/ | ||
dependencyOverrides ++= { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's not worry about lock
right now. removed.
example/src/main/scala/com/avast/server/toolkit/example/Main.scala
Outdated
Show resolved
Hide resolved
@@ -35,6 +35,7 @@ object ConfigurableThreadFactory { | |||
/** | |||
* @param nameFormat Formatted with long number, e.g. my-thread-%02d | |||
*/ | |||
@SuppressWarnings(Array("org.wartremover.warts.DefaultArguments")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
default arguments are frowned upon in the FP community, I personally avoid them too
see https://blog.ssanj.net/posts/2019-05-01-why-are-default-parameter-values-considered-bad-in-scala.html
but this wart applies also to constructors too, which is a big part of PureConfig functionality
so I'm disabling the wart
@@ -4,6 +4,7 @@ import java.util.concurrent.TimeUnit | |||
|
|||
import scala.concurrent.duration.{Duration, FiniteDuration} | |||
|
|||
@SuppressWarnings(Array("org.wartremover.warts.DefaultArguments")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
project/Dependencies.scala
Outdated
val zioInteropCats = "dev.zio" %% "zio-interop-cats" % "2.0.0.0-RC4" | ||
object Versions { | ||
val catsEffect = "2.0.0" | ||
val kindProjector = "0.10.3" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
55bdefb
to
8bd18e3
Compare
.scalafix.conf
Outdated
"scala/Any" | ||
## "scala/Product" # triggers even on non-synthetic | ||
|
||
# local type inference + covariant types fires this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please remove this as it is commented anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
build.sbt
Outdated
|
||
ThisBuild / turbo := true | ||
|
||
lazy val commonSettings = Seq( | ||
lazy val commonSettings = BuildHelper.settingsCommon ++ Seq( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to have commonSettings
and BuildHelper.settingsCommon
? I'd prefer to have object called BuildSettings
and have common
or commonSettings
inside with everything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is what we want. BuildHelper.settingsCommon
contains common settings for Avast Scala projects. commonSettings
contains common settings specific for scala-server-toolkit
modules only. Those 2 are not necessarily the same thing.
BuildHelper.settingsCommon
for example doesn't have any dependency on cats
or scalatest
, and it shouldn't.
project/BuildHelper.scala
Outdated
"-P:silencer:checkUnused" | ||
), | ||
scalacOptions --= { | ||
if (!sys.env.contains("TRAVIS")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove this, I don't think it's needed for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a good idea to fail on warnings in CI
locally, you don't want to fail on warnings, because it break scalafix
workflow unfortunatelly (see the comment in the file below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your effort and sorry for being so strict ;)
PR changed according to our comments.
Uh oh!
There was an error while loading. Please reload this page.