https://github.com/colearendt/multi-dir-deploy
Experimental multi-directory deploys to RStudio Connect
https://github.com/colearendt/multi-dir-deploy
deployment experimental manifest rstudio-connect
Last synced: about 2 months ago
JSON representation
Experimental multi-directory deploys to RStudio Connect
- Host: GitHub
- URL: https://github.com/colearendt/multi-dir-deploy
- Owner: colearendt
- Created: 2019-12-02T13:51:24.000Z (almost 6 years ago)
- Default Branch: master
- Last Pushed: 2019-12-02T14:48:41.000Z (almost 6 years ago)
- Last Synced: 2025-04-08T16:34:32.993Z (6 months ago)
- Topics: deployment, experimental, manifest, rstudio-connect
- Language: HTML
- Size: 293 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# 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](./app.R) (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.