Closed m7pr closed 9 months ago
I can't reproduce this error as I am able to run the code and get the visualization locally.
Could you provide sessionInfo?
I need to make sure you have the same scda
version with the one running in _dev.
@donyunardi I don't say I'm not getting the visualization when I bypass the code and omit the below part
stopifnot(rlang::hash(ADSL) == "843e317c3d4aeb88062cd39a9c62fe8a")
stopifnot(rlang::hash(ADRS) == "601b33239cb66543a69dc57dc923e3f9")
stopifnot(rlang::hash(ADLB) == "b237c364adf16523f5db5bb2035409d9")
stopifnot(rlang::hash(ADLBPCA) == "5b30f523f017d178c7b0695346e9b3f5")
Do you get errors for this part?
For scda
- this package was not changed in the software part for a year so I doubt it's the reason of this.
My session info is below:
Yours: scda.2022_0.1.5.9005 scda_0.1.6.9015
Mine: scda.2022_0.1.5.9000 scda_0.1.6.9008
Mine looks outdated, but last changes are mainly workflow propagations https://github.com/insightsengineering/scda/commits/main/
If we add rlangh::hash
to the resulted code and the dataset is dependent on a version of scda, should we also add a comment about scda version anywhere? By the way, should we use latest release of scda (0.1.6)?
Huh, with the updated version on scda an scda.2022 this passes without errors.
Should we put a limit on scda
and scda.2022
versions in those apps?
So instead of library(scda)
we have:
library(scda)
stopifnot('scda version should be higher than 0.16.9010' = packageVersion('scda') > '0.1.6.9010')
?
A few things here:
scda
is a package with accessor functionalities into scda.xyz (e.g. scda.2022
)scda.2022
is the package where datasets are storedIf you have different version of scda.2022
then not surprisingly you might have different dataset objects thus different hash of that object.
In order to have a match you have to have the same package versions as used in the app you are referring to (latest release for stable deploy and main for devel deploy).
(For simplicity, I'm ignoring maintenance commits that vbumps a given package.)
Should we put a limit on scda and scda.2022 versions in those apps?
In the core functionality? No, definitely not. Not all the apps use scda
datasets.
In the app code? I don't like it tbh. The line you proposed would become outdated on a new change of scda datasets.
I think you reach a known limitation of ShowRCode functionality is that only the code does not guarantee full reproducibility. You have to have the same environment - package versions, sys deps etc. It's quite unfortunate that this ends up being in the top level code component.
This has been identified already and there is an issue to address this problem that is waiting patiently for its time: https://github.com/insightsengineering/coredev-tasks/issues/479
Totally! For sure code is not enough for the reproducibility. The environment is the key. That's why I wonder why we do insist of having stopifnot(rlang::hash
at all in the Show R Code
, as this brings more confusion than benefit. On another hand we were able to troubleshoot the discrepancy between package Versions, so maybe at least we could have a button for Show R Session
to repeat this investigation if someone is alone and does not have another person to help and would like to compare his/her own environment with the environment of the app. I think this should be really quick to develop a functionality that shows R session info.
maybe at least we could have a button for Show R Session to repeat this investigation
How the app would be able to access your local envir? :)
This would have to be a code that you would have to evaluate. That code would have to have app package versions so this would be quite lenghty... IMHO SRC is already too clobbered with library calls. Multiply it by two - ohh gosh nooo...
UPDATE: actually library(foo) && stopifnot(packageVersion(foo) == "1.2.3")
is not that bad - i.e. move it wider and not append at the bottom
UPDATE2: it is actually bad - the goal is to give analysis look alike code but this looks very technical so no
I think this should be really quick to develop a functionality that shows R session info.
You mean to have session info from within the app? It's already there in the footer.
That's why I wonder why we do insist of having stopifnot(rlang::hash at all in the Show R Code, as this brings more confusion than benefit
I don't recall the exact reasons to be honest with you. Probably it's because we wanted to fail fast before the output generation call in case there are differences in the datasets used. If we have different datasets then it's unlikely that we will be having the same outputs.
Do you get errors for this part?
No, that part runs just fine.
Probably it's because we wanted to fail fast before the output generation call in case there are differences in the datasets used.
Correct, I do recall that this was the reason we're using the rlang::hash
, ensuring the integrity of code reproducibility to match what you see in teal
app.
maybe at least we could have a button for Show R Session to repeat this investigation
How the app would be able to access your local envir? :)
No! I meant checking your own session on your own, and app session info in a place where info is shown. I totally missed there is a session info in the footer.
In the end this was a discrepancy of package versions. I would be able to see shiny session info in the footer. I don't think this is a bug in the app. Closing.
What happened?
Go here https://genentech.shinyapps.io/nest_exploratory_dev/ ->
Missing Data
panel. SelectAdd **anyna** variable
(there might be an error even when you dont select it). SelectAdd summary per patients
(there might be an error even when you dont select it). ClickShow R Code
.Code is not runnable
Relevant log output
No response
Code of Conduct
Contribution Guidelines
Security Policy