Skip to content
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

Fix addition of unwanted options to console task #66

Merged
merged 5 commits into from
Apr 22, 2022

Conversation

seveneves
Copy link

#61 broke filtering of console scalacOptions

This is fixed with the help of a new setting key tpolecatExcludeOptions that is used to filter out all options and not just the current additions.

Also, this PR adds tests to console, ThisProject and ThisBuild direct usages of scalacOptions

@seveneves
Copy link
Author

seveneves commented Apr 15, 2022

@DavidGregory084 Addition of the new key and vals broke the binary compatibility with 0.2.0. I guess this is resolvable by a new version 0.3.0. Let me know what you think

… of unwanted options to console task

Fix test reference

Fix test reference

Fix test reference
@DavidGregory084
Copy link
Member

@seveneves I don't mind the addition of new methods (I don't think we should promise forward binary compatibility in this plugin), but I think the main problem is this:

[error]  * method tpolecatConsoleOptionsFilter()scala.Function1 in object io.github.davidgregory084.TpolecatPlugin#autoImport does not have a correspondent in current version
[error]    filter with: ProblemFilters.exclude[DirectMissingMethodProblem]("io.github.davidgregory084.TpolecatPlugin#autoImport.tpolecatConsoleOptionsFilter")

Do you think there is a way that we can make this change and still retain that method? If not I don't mind cutting 0.3.0.

@seveneves
Copy link
Author

seveneves commented Apr 15, 2022

  • method tpolecatConsoleOptionsFilter

Yes of course, it was removed thus it is backwards incompatible. I didn't consider it to be public API till I noticed it's mentioned in the readme.

I think it is possible to change tpolecatExcludeOptions to be accepting a function of Set[ScalacOption] => Set[ScalacOption] that would be performing "modifications" to options. But then you could also add or remove options with it. In this case, the renamed setting key can point to the removed tpolecatConsoleOptionsFilter. This will be a backwards compatible change on the binary level.

But it won't be possible to still keep the following working

IntegrationTest / console / tpolecatScalacOptions ~= tpolecatConsoleOptionsFilter

And I think it is a nicer sbt "API" just to have a Set[ScalacOption] to exclude options that are not needed/unwanted in different scopes. Also, it is clear what is the intention of tpolecatExcludeOptions is. Besides, any additions should be done via += operators to the corresponding settings keys instead of using a function Set[ScalacOption] => Set[ScalacOption]. I think it is more of "natural" sbt way of doing changes to ones build.

But this is just my opinion and you might think differently. Let me know if I should do it via Set[ScalacOption] => Set[ScalacOption]

@seveneves
Copy link
Author

@DavidGregory084 ☝️
forgot to tag you

val filters = scalacOptionsFor(scalaV, tpolecatExcludeOptions.value).toSet
val newOptions = scalacOptionsFor(scalaV, tpolecatScalacOptions.value)
(previous ++ newOptions).filterNot(filters).distinct
}
),
tpolecatDevModeOptions := ScalacOptions.default,
Copy link
Author

Choose a reason for hiding this comment

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

@DavidGregory084 I would also move this to build or global settings as "common" defaults. If one uses ThisBuild / tpolecatDevModeOptions it will have same problems as did scalacOptions in #60. Wdyt?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah we can definitely try that!

@DavidGregory084
Copy link
Member

And I think it is a nicer sbt "API" just to have a Set[ScalacOption] to exclude options that are not needed/unwanted in different scopes. Also, it is clear what is the intention of tpolecatExcludeOptions is. Besides, any additions should be done via += operators to the corresponding settings keys instead of using a function Set[ScalacOption] => Set[ScalacOption]. I think it is more of "natural" sbt way of doing changes to ones build.

Yes I totally agree - when the consoleOptionsFilter was first added it was inspired by a recommendation I saw for filtering out scalacOptions for use with Tut and I didn't really think a great deal about it at the time!

@@ -129,7 +123,13 @@ object TpolecatPlugin extends AutoPlugin {

override def projectSettings: Seq[Setting[_]] = Seq(
Def.derive(
scalacOptions ++= scalacOptionsFor(scalaVersion.value, tpolecatScalacOptions.value)
scalacOptions := {
Copy link
Member

Choose a reason for hiding this comment

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

I have just noticed the change from ++= back to := - does that still behave correctly in relation to the issue you saw on #60?

Copy link
Author

@seveneves seveneves Apr 22, 2022

Choose a reason for hiding this comment

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

Yes. Look at the back reference of scalacOptions.value in the body of the task

Copy link
Member

Choose a reason for hiding this comment

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

Cool, just wanted to understand whether it affected the fix of the previous issue 😛

Copy link
Author

Choose a reason for hiding this comment

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

I added a test to catch the problem. It should be working :)

@DavidGregory084
Copy link
Member

DavidGregory084 commented Apr 22, 2022

Other than the question about := vs ++= this looks great to me.

In order to unblock your build I think we need to set mimaPreviousArtifacts in build.sbt to Set.empty on this PR until we can publish 0.3.0.

We can also empty out the mimaBinaryIssueFilters as they will no longer be relevant for 0.3.0!

@seveneves
Copy link
Author

In order to unblock your build I think we need to set mimaPreviousArtifacts in build.sbt to Set.empty on this PR until we can publish 0.3.0.
We can also empty out the mimaBinaryIssueFilters as they will no longer be relevant for 0.3.0!

I set both of them to empty values. I'm not entirely sure how to populate mimaBinaryIssueFilters back.

@DavidGregory084
Copy link
Member

I set both of them to empty values. I'm not entirely sure how to populate mimaBinaryIssueFilters back.

That's absolutely fine - since we are going to move to a new reference "mimaPreviousArtifact" there will be no binary compatibility issues to filter out, hopefully that makes sense. The existing filters were there to ignore methods that were added since 0.2.0.

@DavidGregory084 DavidGregory084 merged commit 6494873 into typelevel:main Apr 22, 2022
@DavidGregory084
Copy link
Member

Thanks for this @seveneves!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants