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.