Controlling/ debugging RStudio Connect app bundles

Posit Professional & Hosted Products Posit Connect
1

For some reason an app that I regularly update (add new data and publish changes) stopped working recently. Everytime I go to publish a new version everything goes well until the end when it spits out the error:

2019/07/03 19:24:10.328726187 Collecting cloud-init==18.4 (from -r requirements.txt (line 10))
2019/07/03 19:24:10.331058250   ERROR: Could not find a version that satisfies the requirement cloud-init==18.4 (from -r requirements.txt (line 10)) (from versions: none)
2019/07/03 19:24:10.391276831 ERROR: No matching distribution found for cloud-init==18.4 (from -r requirements.txt (line 10))
2019/07/03 19:24:10.428967159 Error during installation: pip install failed with exit code 1; removing environment from cache: /opt/rstudio-connect/mnt/python-environments/pip/3.5.2/FksHjyEMz0iHobEq5mAYpg
2019/07/03 19:24:10.444992294 pip install failed with exit code 1
Build error: exit status 1

I have a working python install on this connect server and it is enabled (following the instructions in the connect admin guide) but more importantly I don't use any python calling packages in this app at all (and I haven't changed the packages since previous installs). I looked into what has changed between the last successful deployment and now by downloading the manifest.json from the deployments from the connect interface and then looked at what packages had changed with

library(tidyverse)
good_manifest <- jsonlite::read_json('~/Downloads/bundle-147/manifest.json')
bad_manifest <- jsonlite::read_json('~/Downloads/bundle-165/manifest.json')

get_pkgs <- . %>% 
  pluck("packages") %>% 
  names()

good_pkgs <- get_pkgs(good_manifest)
bad_pkgs <- get_pkgs(bad_manifest)

bad_pkgs[!(bad_pkgs %in% good_pkgs)]
# [1] "reticulate" "vctrs" "zeallot"

So reticulate was added as a dependency somehow.

In addition, there was a new top-level field called 'Python' in the manifest that wasn't there in the working version of the deployment.

Attempt to fix

I attempted to see what was going on by running the command rsconnect:::performPackratSnapshot(".") as is suggested in the Connect Admin Guide and the generated snapshot doesn't have reticulate in it. However when I attempted to deploy again from the app with the packrat.lock file it seemed to ignore it and I got the same error.

Main Question

My main question is: is there anyway to customize what gets added to the 'needed libraries' section of deployment?

Thanks so much for any help you can provide! I've been banging my head against a desk for a whole day on this!

2

Solution to my issue

I seemed to fix this by removing {usethis} from my environment. A funky situation given that I don't see any Python dependencies in the {usethis} DESCRIPTION but oh well.

The main question still stands, however. How do you take manual control of the generation of connect deployment images? I even attempted to wrap everything in a {packrat} project and the issues came through then.

3

@nstrayer is it possible that usethis brings in a dependency that could bring in reticulate? Did the version of usethis or any of the other packages change between manifests?

Today, you can not supply your own manifest to the push button publishing process.

However, you could decide to deploy via a different mechanism, such as from Git (a new addition in the latest release of Connect), in which case you can control the manifest that is used.

https://solutions.rstudio.com/deploy/methods/

Another suggestion, have you considered other ways to update your data aside from re-publishing? Would it make sense to use a scheduled RMD to update the data? For example, see: https://medium.com/@kelly.obriant/basic-builds-how-to-update-data-in-a-shiny-app-on-rstudio-connect-48593902b1e2

1 Like
4

Hi Sean,

Thanks for the help!

I guess usethis must be doing something like that, just not in a transparent way.

Interesting to know about the manifest control with git deploy.

Currently we're just dumping flat files in with the app upload for new data, the reason for this is because we haven't invested the time to setup a database/ other datasource method for connecting in a secure and easy-to-update way. Perhaps this incident will prompt that time investment.