-
-
Notifications
You must be signed in to change notification settings - Fork 73
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
Make os.home a def #239
Make os.home a def #239
Conversation
Maybe make |
You can make a private private lazy val _home = Path(System.getProperty("user.home"))
def home: Path = _home |
cc47d2d
to
f7a89bf
Compare
Is there a reason the JVM implementation is just a |
You're right, they should both be lazy |
If you update the PR I think we can merge it and release a new version. |
os/test/src/OpTests.scala
Outdated
test("pwd when home is not available") { | ||
val correctPwd = java.nio.file.Paths.get(".").toAbsolutePath | ||
val oldUserHome = System.getProperty("user.home") | ||
System.setProperty("user.home", "?") |
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.
This test doesn't test the behavior because the package object is already initialized when you call this method.
I tried running it on main and it passes.
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.
Right, then I guess there are no tests present that could capture that, I reverted the changes.
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.
I think having no unit tests are fine. We could go with an integration test in a separate test target that sets the user.home
explicitly, but IMO this is a straightforward enough change to land as is
f7a89bf
to
dc241cd
Compare
Looks like MIMa is complaining still. Can you take a look and see if those errors are legitimate or not? If they're false positives we should whitelist then in the build file |
If changing val to def is not binary compatible, Another possible solution can be to return a |
The |
@sake92 What about |
I wonder what the expected behavior of any app could be, if there is no |
Also, isn't it possible when booting an app to always statically set the |
Oh, I chimed in and question the whole PR, because I read the trigger word |
Well, failing when
life would be better. On the other hand, what's the gain of moving the responsibility to the user adding an ugly fix in the |
@MaciejG604 Sorry, I might have missed the point. Your idea is to let Re the concerns of @sake92, I think in an earlier version of the PR where there was a pure |
I think the current code is fine, we just need to figure out how to make MIMA happy |
This is binary compatible and still eager: private val _home = scala.util.Try(Path(System.getProperty("user.home")))
/**
* The user's home directory
*/
def home: Path = _home.get When the code throws it suspends the exception for when the home method is actually used. |
Interesting. I think, this may come to a surprise. Time-traveling exceptions may be perceived as a code path executed a second time. What about this? private object _home {
lazy val value = Path(System.getProperty("user.home"))
}
def home: Path = _home.value This has the advantage, that it's still lazy, so it could be worked around in a |
@lefou good point. private object _home {
val value = Path(System.getProperty("user.home"))
}
def home: Path = _home.value EDIT: |
Since we're now initializing |
@lolgab is there a reason you wrapped the |
Adding a private lazy val introduces a binary incompability on Scala 3, while an |
Got it. Can we open an issue on the dotty repo? adding private members breaking binary compatibility seems like a language problem |
I think we should leave a comment in the code, describing why we make it lazy and why it's inside an object, for future maintainer. |
Anyways we have tests for all scenarios.
I'm not sure it's an actual problem or something that is not a problem but MiMa doesn't know about it. |
Can we try upgrading to scala 3.3.1 and seeing if the problem still exists? It should be ok to force 3.3.x since that their official LTS version We dont need to fix the issue in this PR if it's due to some upstream code, but we should try to at least pinpoint which one is problematic and open an issue |
I tried to bump to |
+1. It's a new |
I'm happy with merging the code as is, but i would like a comment with a link to a ticket either on the mima or on the dotty repo. Even if we don't know the root cause of the bincompat issue now, such a ticket would provide a route for follow on discussion and a path to either fixing or understanding what is a pretty weird workaround |
Opened an issue in MiMa. Thank You for working on this! |
Thank you, @MaciejG604 ! |
In some environments the home directory is not configured, thus
user.home
can be set to e.g. "?" (like in the issue the Scala CLI team has bumped into). See OpenJDK sourcesIn those cases using e.g.
os.pwd
throws, since theos.home
is also initialized.This fix allows
os.pwd
to still be used whenuser.home
is set to something weird.One example of such environment with
user.home
set to "?" is running Jenking on CloudBees, the results of trying to run Scala CLI there looked like this, since we heavily use os.pwd in our code base:Pull request: #239