Skip to content

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

Merged
merged 15 commits into from
Oct 2, 2019
Merged

Conversation

sideeffffect
Copy link
Contributor

@sideeffffect sideeffffect commented Sep 24, 2019

image

Copy link
Collaborator

@jakubjanecek jakubjanecek left a 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"))
Copy link
Collaborator

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.

Copy link
Contributor Author

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

Copy link
Collaborator

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.

Copy link
Contributor

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.

@jakubjanecek jakubjanecek self-assigned this Sep 24, 2019
# Conflicts:
#	build.sbt
#	example/src/main/scala/com/avast/server/toolkit/example/Main.scala
#	project/Dependencies.scala
@sideeffffect sideeffffect changed the title pimp my sbt Improve my car... ehh... sbt Sep 24, 2019
@sideeffffect
Copy link
Contributor Author

@jakubjanecek build is green, ready to merge from my POV. we can talk about details in person tomorrow if you want

@sideeffffect sideeffffect dismissed jakubjanecek’s stale review September 24, 2019 21:02

implemented suggestions

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 ++= {
Copy link
Contributor

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?

Copy link
Collaborator

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.

Copy link
Contributor Author

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"))
Copy link
Contributor

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?

Copy link
Collaborator

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.

Copy link
Contributor Author

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

@jakubjanecek
Copy link
Collaborator

@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 :)

augi
augi previously requested changes Sep 25, 2019
Copy link
Member

@augi augi left a 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.

val zioInteropCats = "dev.zio" %% "zio-interop-cats" % "2.0.0.0-RC4"
object Versions {
val catsEffect = "2.0.0"
val kindProjector = "0.10.3"
Copy link
Member

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

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.

Copy link
Collaborator

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...

Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -4,6 +4,7 @@ import java.util.concurrent.TimeUnit

import scala.concurrent.duration.{Duration, FiniteDuration}

@SuppressWarnings(Array("org.wartremover.warts.DefaultArguments"))
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✔️

Copy link
Contributor

@hanny24 hanny24 left a 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.

@jakubjanecek
Copy link
Collaborator

@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:

  • Adding scalafix but with less rules (the ones that are not controversial and work well across the codebase.
  • Marking test dependencies at the place of use. However please keep the versions inlined and do not refactor them to a special object (there's really no need for that, at least now).
  • Removing the SCM info.
  • Maybe adding some warts but definitely not all of them like now.

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
Copy link
Contributor Author

@sideeffffect sideeffffect left a 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 ++= {
Copy link
Contributor Author

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"))
Copy link
Contributor Author

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"))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✔️

val zioInteropCats = "dev.zio" %% "zio-interop-cats" % "2.0.0.0-RC4"
object Versions {
val catsEffect = "2.0.0"
val kindProjector = "0.10.3"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sideeffffect sideeffffect reopened this Oct 1, 2019
.scalafix.conf Outdated
"scala/Any"
## "scala/Product" # triggers even on non-synthetic

# local type inference + covariant types fires this
Copy link
Collaborator

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?

Copy link
Contributor Author

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(
Copy link
Collaborator

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.

Copy link
Contributor Author

@sideeffffect sideeffffect Oct 2, 2019

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.

"-P:silencer:checkUnused"
),
scalacOptions --= {
if (!sys.env.contains("TRAVIS"))
Copy link
Collaborator

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.

Copy link
Contributor Author

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)

Copy link
Collaborator

@jakubjanecek jakubjanecek left a 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 ;)

@jakubjanecek jakubjanecek dismissed stale reviews from hanny24 and augi October 2, 2019 13:41

PR changed according to our comments.

@jakubjanecek jakubjanecek merged commit ec97702 into avast:master Oct 2, 2019
@sideeffffect sideeffffect deleted the pimp-my-sbt branch October 2, 2019 14:07
@jakubjanecek jakubjanecek added the feature New feature or request label Oct 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Development

Successfully merging this pull request may close these issues.

5 participants