-
Notifications
You must be signed in to change notification settings - Fork 186
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
sbt-scalafix should be able to read resolver credentials from the filesystem #1571
Comments
Thanks for the report. I agree it's currently a pain for corporate users that resolvers and credentials are not inherited from sbt.
The last file seems to be opened at least, maybe you are not using the right format?
Check out scalameta/sbt-scalafmt#108 (comment), since it's essentially the same environment. |
Thanks @bjaglin I'm going to experiment with that coursier file and see if we can make it work. Will report back! |
@nasadorian any update on this? |
@nasadorian please reopen if you still have the issue |
@bjaglin Thanks for the followup, and I don't remember what ended up happening with this. I haven't written Scala since the year this issue was opened, sadly. |
When overriding the resolvers used by
sbt-scalafix
, we use thescalafixResolvers
key to specify custom (internal corporate) resolvers. The types used by this key are different from SBT's Resolver class and are instead from the Coursier API, and they only accept credentials programmatically. The plugin does not seem to respect the contents of~/.sbt/repositories
nor~/.ivy2/.credentials
nor~/.config/coursier/credentials.properties
.It would be nice to have
sbt-scalafix
adhere to the same resolvers as SBT itself, though I'm not sure how feasible that is.As a stop-gap, what if the plugin could read credentials files instead to configure itself? Right now the only solutions I see when using custom resolvers are to read user and pass from environment variables or parse an existing credentials file like the below.
The text was updated successfully, but these errors were encountered: