Skip to content
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 data available #19

Open
maxheld83 opened this issue Sep 15, 2020 · 9 comments
Open

make data available #19

maxheld83 opened this issue Sep 15, 2020 · 9 comments

Comments

@maxheld83
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Collaborator

njahn82 commented Sep 15, 2020 via email

@njahn82
Copy link
Collaborator

njahn82 commented Sep 15, 2020 via email

@maxheld83
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Collaborator

njahn82 commented Sep 15, 2020 via email

@maxheld83
Copy link
Contributor Author

maxheld83 commented Sep 15, 2020

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

@maxheld83
Copy link
Contributor Author

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://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 #12, this might not be worth it.

So I might not actually fix this.

@maxheld83 maxheld83 transferred this issue from subugoe/oauni_10_18 Oct 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants