-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Change scalafixResolvers to come from Coursier defaults so can be overridden #159
Change scalafixResolvers to come from Coursier defaults so can be overridden #159
Conversation
I'll add, this would be for running
I also tried using the
That token is a session token, though, not a personal access token, so it expires after a few days. You can use a Github personal access token to get raw github files using the api and passing headers, like:
To make this work, |
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.
LGTM, thanks for the detailed explanation!
What would be great would be to document & prevent regressions against that in a scripted test that would run a rule available via a non-standard, public resolver declared in COURSIER_REPOSITORIES
. I don't know of any though, do you by any chance?
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.
+1 to using the user's configured resolvers instead of any "hard-coded" resolvers
scalafixResolvers := Seq( | ||
Repository.ivy2Local(), | ||
Repository.central(), | ||
scalafixResolvers := Repository.defaults().asScala.toSeq ++ 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.
Should this only happen if useCoursier := false
(from the SBT docs).
Maybe it makes more sense to just to tap into SBT's default resolvers?
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.
Should this only happen if useCoursier := false (from the SBT docs).
As of now, as you mention, scalafix
is bypassing the sbt
resolvers, so I don' think the sbt setting useCoursier := false
applies to setting the scalafixResolvers
. This may come into play if your next suggestion is implemented, though?
Maybe it makes more sense to just to tap into SBT's default resolvers?
For the particular problem I'm trying to solve at Rally, yes, this would work without needing an env variable override. Assuming all scala projects are using the rally-sbt-plugin
(private to Rally), which puts https:///ivy-libs-snapshot in globalSettings
, and our private scalafix rules are published to the same https:///ivy-libs-snapshot, then using SBT's default resolvers for each repo would work for a tool like scala-steward
.
Since scala-steward
adds sbt-scalafix
to repos on the fly, I could see a scenario where the repos' configured SBT resolvers are not the same as the custom resolver where the scalafix rules are hosted, in which case the env variable would still be desired to add additional custom resolvers.
e71fdea
to
329ab37
Compare
I agree this would be a good test. But no, I'm aware of a public non-standard resolver that hosts public scalafix rules. I took a look through the public scalafix rules scala-steward is adding by default, but didn't find any that are publishing to a resolver other than sonatype / Maven central. I setup the test to just verify that |
95627cc
to
87e9474
Compare
87e9474
to
e0c68bb
Compare
@bjaglin Do you think this test is sufficient? |
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.
Wonderful, thank you for figuring out a way to prevent this from regressing!
# reload to ensure env variable COURSIER_REPOSITORIES is picked up by scalafixResolvers | ||
> reload |
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.
out of curiosity, is the reload required by sbt-dotenv
for the env file to be applied?
The impetus for this proposed change is trying to use privately hosted
scalafix
rules withscala-steward
. Currently, the scalafix tutorial describes how to add custom scalafix resolvers in a project'sbuild.sbt
. Since scala-steward adds the sbt-scalafix plugin on the fly, however, it would further need to edit a project'sbuild.sbt
in order to add custom resolvers, which would be tricky.The alternative I'm proposing here sets the
scalafixResolvers
to Coursier'sdefaultRepositories
. The defaults are the same as previously set -Repository.ivy2Local()
andRepository.central()
. But usingdefaultRepositories
allows overriding the repositories via theCOURSIER_REPOSITORIES
environment variable, as documented here and shown in thedefaultRepositories
code.I've tested this code locally with first doing
and then running
sbt-scalafix
on a repo (without overriding thescalafixResolvers
), and verified it picks up thescalafix
rules which exist only in the private ivy artifactory resolver.When trying to run
scala-steward
to apply the privately hostedscalafix
rules, the current error I'm getting is:which I expect this proposed change to resolve. If this change is accepted, I will update the
scala-steward
running docs to explain how addingexport COURSIER_REPOSITORIES="ivy2Local|central|somePrivateRepository"
before runningscala-steward
allows applying privately hostedscala-fix
rules.