Closed MichaelChirico closed 9 months ago
Merging #1129 (99d64b2) into main (c38d7f9) will not change coverage. The diff coverage is
n/a
.:exclamation: Current head 99d64b2 differs from pull request most recent head 3a13ef6. Consider uploading reports for the commit 3a13ef6 to get more accurate results
@@ Coverage Diff @@
## main #1129 +/- ##
=======================================
Coverage 92.35% 92.35%
=======================================
Files 46 46
Lines 2654 2654
=======================================
Hits 2451 2451
Misses 203 203
This is how benchmark results would change (along with a 95% confidence interval in relative change) if 8f839e601c2c560275344ce9969cbe8932dca661 is merged into main:
Further explanation regarding interpretation and methodology can be found in the documentation.
normalizePath() throws a warning here
In my understanding, a warning is given if the path does not exist. Also, in the help file, searching for writ does not give any results.
So is it non-existant or non-writable?
So is it non-existant or non-writable?
I think non-extant because non-writable.
I think non-extant because non-writable.
Really? Or the other way round?
@MichaelChirico happy to help here, can you catch up?
Sure, what else would you like to see in the PR before merge?
This is how benchmark results would change (along with a 95% confidence interval in relative change) if c38d7f98725822061307748ec2eef2c45c5fa25c is merged into main:
Further explanation regarding interpretation and methodology can be found in the documentation.
I think non-extant because non-writable.
I don’t understand that. Can you explain?
i.e. the process doesn't have permission to write to that directory, so it can't create the expected file(s).
Ok thanks. @IndrajeetPatil seems link rot check not working anymore. Can you habe a look?
We have a strange setup where
tools::R_user_dir()
won't be writeable during testing, sonormalizePath()
throws a warning here. The code works as expected after the warning (cache is just deactivated), so settingmustWork=FALSE
here seems reasonable.OTOH, this might be pretty unique to our testing systems, so if it's too niche an issue we'll just maintain this patch in our fork.