Multi Dir Deploy - EXPERIMENTAL

HACKY EXPERIMENT: DO NOT USE

To try:

• Copy manifest_rmd.json or manifest_shiny.json to manifest.json
• Use bnd <- connectapi::bundle_dir()
• Deploy with connectapi::deploy(connectapi::connect(), bnd)

Important Notes

• Rmd requires changing the manifest.json to specify the proper subdirectory
• Shiny requires a little wrapper to run the app properly
• Working directory is different when run this way… and can cause problems
• manifest.json must be the name of the manifest, so the client has to be
  smart enough to change dynamically

Pain Points

• Working Directory? The IDE knows how to set the working directory when
  running a Shiny application. If I want to reference the helpers folder, do I
  use ../helpers from the app’s perspective, or ./helpers from the root? What
  about a local .css file usually referenced directly? Do I need to specify the
  app directory? Working directory problems are hard for users to reason about,
  especially in non-interactive contexts like Connect. I used rprojroot to solve
  this problem, but I see users mostly using here::here() (which has been known
  to cause problems on Connect). There may need to be some IDE functionality or
  user training / conventions to make this easier for users.

• Which files? The IDE usually scopes deployments to just a directory with
  an app and gives me a nice file selector. How do I figure out which files to
  include? This experiment includes the WHOLE DIRECTORY (every time) and only
  pivots based on the manifest. Some IDE functionality would be helpful here,
  along with some type of simple file format structure (a part of the manifest? an
  “ignore” file?) that makes clear what files to include. The .dcf format does
  this but is hard to reason about because it is pipe delimited. Further, this is
  hard to marshal for git-backed content / programmatic deployment.

• Which manifest? Although rsconnect could dynamically build the manifest
  somehow, the root directory needs to be the basis (which is different from the
  current pattern of the “app” directory). Further, things get tricky with
  programmatic / git-backed deployment, because Connect only understands the notion
  of a single manifest.json. So we will either need smarter clients (to rename /
  rewrite manifests) or Connect to somehow allow the manifest to be specified.

• Inconsistent manifest specifications The Shiny deployment method just
  looks for an app.R (or maybe some other types of .R files?), and does not
  allow specification in the manifest. Rmd allows the specification of the
  “primary document.” As a result, I wrote a hacky wrapper (which is
  not advisable). The manifest is inconsistent, uses unclear heuristics, and is
  therefore a bit hard for a user to reason about here. It would be nice if the
  manifest was consistent and explicit about what it was going to do, so that it
  is easier to reason about.

• What is going on on Connect? I specified the wrong “primary document”, had
  forgotten to update the manifest.json, and struggled through the working
  directory / other issues above. Ultimately, a pattern for “inspecting the
  bundle” as a publisher would potentially help the debugging process a bit. At a
  minimum, maybe this would be inspecting the manifest? Further, when developing
  the Shiny wrapper, Connect and the IDE behaved differently regarding runApp().
  The non-interactive context makes things challenging to debug, so more exposure
  here might be nice to support a more complex / complicated workflow. I.e. can I
  see what the working directory is? The content being executed? The list of
  packages being used?

• A way to link these deployments together If these deployments are related,
  is it possible for them to link to each other? Reference one another as “peers”
  or “co-dependents”? What if one has a strict dependency on the other? I.e. a
  pin, Rmd updating a pin, Rmd ETL, etc.