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

Scalafmt seems to ignore COURSIER_REPOSITORIES #3316

Closed
PawanKartikS opened this issue Sep 7, 2022 · 8 comments · Fixed by #3621
Closed

Scalafmt seems to ignore COURSIER_REPOSITORIES #3316

PawanKartikS opened this issue Sep 7, 2022 · 8 comments · Fixed by #3621

Comments

@PawanKartikS
Copy link

PawanKartikS commented Sep 7, 2022

Our environment does not support egress so we use Nexus repository manager. While we are able to use coursier to fetch what we want by specifying COURSIER_REPOSITORIES AND COURSIER_CREDENTIALS, scalafmt seems to hit oss.sonatype.org while resolving the version specified in the .scalafmt.conf file. If the former env variable isn't set, it straight away goes to maven. Am I correct in assuming that scalafmt supports COURSIER_REPOSITORIES, ref? If it does indeed support it, shouldn't it hit our Nexus instead?

Version: 3.5.9

Additional helpful information:
I've tried running coursier to fetch something which hit our Nexus and was successful. The next immediate command that I ran was scalafmt as scalafmt Foo.scala --debug which hit some other endpoint/host instead of our Nexus. And because the egress is blocked, it simply sat there with the progress bar at 0%. I've double checked that the env variables are correct. Coursier being able to pull what I've asked for also shows that the configuration is correct.

Configuration

version = 3.5.9
...

Command-line parameters

scalafmt Main.scala --debug

Expectation

I'd expect that scalafmt format the code as per its functionality.

@tanishiking
Copy link
Member

tanishiking commented Sep 7, 2022

Hey, @PawanKartikS thank you for reporting!
I tried to reproduce it with, for example

COURSIER_REPOSITORIES="jitpack" ./scalafmt --debug

but scalafmt correctly try to resolve from jitpack, and failed (because there's no binary on jitpack) then fallback to sonatype which is a default repository set by scalafmt.
Which repository did you specify by COURSIER_REPOSITORIES?

@PawanKartikS
Copy link
Author

I just specified 1 repository, our Nexus endpoint.

@tanishiking
Copy link
Member

Can you download the scalafmt binary from the Nexus repository?
scalafmt-cli does indeed support COURSIER_REPOSITORIES.

@PawanKartikS
Copy link
Author

./cs bootstrap org.scalameta:scalafmt-cli_2.13:3.5.9 --verbose --standalone -o /some_path/scalafmt
This command pulls 3.5.9 from Nexus. Is this what you're asking?

@tanishiking
Copy link
Member

Hmm, then I have no idea what's going on in your environment 🤔

@PawanKartikS
Copy link
Author

PawanKartikS commented Sep 8, 2022

I have an update for you. I'm not sure how relevant it is but I thought I should point it out. When scalafmt is invoked, it very briefly, for a sec, hits our Nexus repo and then switches back to oss.sonatype.org. It happens so quickly that it was nearly impossible to notice. I had to record my screen and move frame by frame to notice this happen. Are there any scenarios where the scalafmt would switch the repo it is using without facing any error?

@tanishiking
Copy link
Member

tanishiking commented Sep 8, 2022

That happens if the binary is not found in the repository (that's why I asked "Can you download the scalafmt binary from the Nexus repository?")
Can you find org.scalameta:scalafmt-core_2.13:3.5.9 from your nexus repository instead of scalafmt-cli (I guess you can though...)

@PawanKartikS
Copy link
Author

PawanKartikS commented Sep 8, 2022

Yes, I just pulled in org.scalameta:scalafmt-core_2.13:3.5.9 successfully and I can confirm that I was able to view it from within our repo manager. I even was able to pull a few other versions.

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

Successfully merging a pull request may close this issue.

2 participants