make data available

[maxheld83]

the objects in data are currently not available on a system, if the package is devtools::install()ed, and also not during testing. It appears that the data is only available as exported objects after devtools::load_all().

So that appears to be a reproducibility bug.

Because a docker image, and by extension Azure requires a properly installed and working package, this currently makes it impossible to deploy the app.

[maxheld83]

ok, I think the problem is that by default behavior, data is available only when the package is loaded (i.e. library()ed). Without this, the data might need a data() wrapper.

[njahn82]

Would golem::add_dockerfile() help? https://engineering-shiny.org/deploy-golem.html

On Tue, 15 Sep 2020 at 16:17, Max Held notifications@github.com wrote:

ok, I think the problem is that by default behavior, data is available only when the package is loaded (i.e. library()ed). Without this, the data might need a data() wrapper.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/subugoe/oauni_10_18/issues/24#issuecomment-692745313, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM7YRTFFSBABCW3FPCX4I3SF5ZQNANCNFSM4RNFY2FA .

[njahn82]

I also forgot to add this file https://github.com/subugoe/oauni_10_18/blob/master/app.R

On Tue, 15 Sep 2020 at 17:23, Najko Jahn najko.jahn@gmail.com wrote:

Would golem::add_dockerfile() help? https://engineering-shiny.org/deploy-golem.html

On Tue, 15 Sep 2020 at 16:17, Max Held notifications@github.com wrote:

ok, I think the problem is that by default behavior, data is available only when the package is loaded (i.e. library()ed). Without this, the data might need a data() wrapper.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/subugoe/oauni_10_18/issues/24#issuecomment-692745313, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM7YRTFFSBABCW3FPCX4I3SF5ZQNANCNFSM4RNFY2FA .

[maxheld83]

this can be reproduced in a fresh session thus (from this branch):

devtools::install()
oadash::run_app()

calling library() before solves the issue.

devtools::install()
library(oadash)
oadash::run_app()

I think I'm gonna go with that hack in the Dockerfile for now and get back to this later.

My hypothesis is that it's a collation order issue, though I couldn't find anything on it.

Strewing in data() calls for the side effect seemed to work, but it felt hacky. Perhaps documenting the datasets will do the trick.

[maxheld83]

Would golem::add_dockerfile() help? https://engineering-shiny.org/deploy-golem.html

I don't think this is a golem issue, and I've now isolated it out of docker, so it's not even a docker image. I think I have a hack for now, will get back to this later.

[maxheld83]

I also forgot to add this file https://github.com/subugoe/oauni_10_18/blob/master/app.R

no problem I'll merge it in!

[njahn82]

Agreed, the data are not documented, yet

On Tue, 15 Sep 2020 at 17:38, Max Held notifications@github.com wrote:

Would golem::add_dockerfile() help? https://engineering-shiny.org/deploy-golem.html

I don't think this is a golem issue, and I've now isolated it out of docker, so it's not even a docker image. I think I have a hack for now, will get back to this later.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[maxheld83]

looks like this might be a golem problem after all: https://github.com/ThinkR-open/golem/issues/413 A different fix should work now.

[maxheld83]

this one is a bit of a doozy 🙃

I've now given up, and deployed to shinyapps.io (again 😕) for now, until subugoe/oa-german-inst#14. The problem does not appear on shinyapps.io, probably because shinyapps.io does not deploy apps as "packages", and relies on black magic anyway. This is not a long-term solution, because a) shinyapps.io has a habit of breaking, b) we don't want it, and c) most importantly, this bug defeats the purpose of golem and generally shipping shiny as an R package.

I do not have a definitive idea of what's going on, but https://github.com/ThinkR-open/golem/issues/413 looks conspicuously similar. Golem's run_app() is unique and might explain this (or not). The problem might also not be on golem's end, but it sure doesn't make it easier to debug (related subugoe/oa-german-inst#12, https://github.com/subugoe/muggle/issues/59).

I have tried, all to no avail:

• just running load_all() in the CMD instruction
• namespacing all the data object calls as in oadash::foo
• switching LazyData : false
• documenting the data (that shouldn't affect it really)
• manually changing the collation order
• just placing data() calls somewhere in the code
• ... and a bunch of other things.

Always, run_app() would fail with something like:

Warning: Error in : 'oa_shares_inst_sector' is not an exported object from 'namespace:oadash'
  101: stop
  100: getExportedValue
   99: ::
   70: ui [/app/R/app_ui.R#10]

Even though clearly, the object was an exported object when tested interactively.

I have two broad hypothesis:

1. Still, collation order in some weird way. Maybe when the ui_foo() etc. functions get compiled (at build time), the data objects are not available yet (?). This doesn't really make much sense, because that would then affect lots of R packages.
2. Maybe, run_app() somehow interferes with LazyData or compilation.

Anyway, unless I magically stumble across the solution, I would not investigate this further. The way to go further would be to build a reprex from scratch, which would take some time.

Given the other needs for a relaunch, and especially subugoe/oa-german-inst#12, this might not be worth it.

So I might not actually fix this.