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 ***@***.***> 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:/subugoe/oauni_10_18/issues/24#issuecomment-692745313>, or unsubscribe <https:/notifications/unsubscribe-auth/AAM7YRTFFSBABCW3FPCX4I3SF5ZQNANCNFSM4RNFY2FA> .

[njahn82]

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

…

On Tue, 15 Sep 2020 at 17:23, Najko Jahn ***@***.***> wrote: Would `golem::add_dockerfile()` help? https://engineering-shiny.org/deploy-golem.html On Tue, 15 Sep 2020 at 16:17, Max Held ***@***.***> 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:/subugoe/oauni_10_18/issues/24#issuecomment-692745313>, > or unsubscribe > <https:/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:/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 ***@***.***> 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: ThinkR-open/golem#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 #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 ThinkR-open/golem#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 #12, https:/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 #12, this might not be worth it.

So I might not actually fix this.