Deploying R and Python Apps on Posit Connect: Key Differences

I ended my previous post Using uv to manage the environment for a Python Shiny app and setting up a GitHub action
to publish it to Posit Connect with:

Posit Connect can only listen to branches, so the idea is to have a deploy branch which Connect publishes, but which is managed by GitHub actions.

It seems this is not correct.

The Python deployment

Initially I was looking to publish a Python Shiny app, and indeed the rsconnect-python package seems to be able only to deploy new content even when there are no changes to the manifest.json file.

Below you can see that there are two pyshinywikidata deployments, but it is the same app. It is just what happens when I run the pipeline twice.

In other words, it seems that the command:

uvx --from rsconnect-python rsconnect deploy manifest --server=$CONNECT_SERVER --api-key=$CONNECT_API_KEY manifest.json

does not recognize that there is already an existing content with the same manifest file on the server.

The R deployment

However, this is not the case with deploying an R Shiny app. In particular, this seems not to be the case when deploying an R Shiny app using the RStudio actions provided by Posit. This one is focused on R and doesn’t show in Google searches when looking to deploy a Python app.

Using this action in a workflow makes it possible to update existing deployments, which is great.

However, the R way of doing things has some other strange quirks, most notably that the renv.lock file should be kept updated in the repository as well. This complicates things a bit when the app that needs to be deployed is written with {golem}.

In this case, renv.init() does not know that the app needs to be installed in the deployment too, in order to be loaded. And, that additional packages are required as well. Therefore, adding these dependencies has to happen manually with renv::record(). Besides the packaged app, four more packages need to be added with renv.record(): pkgload, pkgbuild, desc, and procesx.

This complicates matters a bit, because it is another manual step that can be easily forgotten, and in that case the deployment will fail.

This is because, as the renv FAQ explains:

For a package to be recorded in the lockfile, it must be both: 1. Installed your project library, and 2. Used by the project, as determined by renv::dependencies().

Altering the renv settings may be the best approach as described in the FAQ too.

The Python deployment, again

But, if the action exists, can it be used for Python apps as well?

The answer to that is yes.

Digging through the repository for RStudio actions, and the TypeScript client library for the Posit Connect API I found out that the good people at Posit have written tests for deploying a Flask app (which is Python!). So if it works for Flask it will work for Shiny, and indeed it does.

It seems to me that rsconnect-ts offers a bit more flexibility than rsconnect-python. As far as I can tell, I cannot use rsconnect-python to check if content already exists. At the same time, it seems the rsconnect-ts, still being a beta-quality package, is not really being advertised, or maybe not even been work on actively.

Summary

In this article I tried to clarify some of my confusion regarding using GitHub Actions to deploy R and Python Shiny apps, and probably I added a bit of new confusion as well. I will try to keep this series updated as I learn new things or better ways to achieve gh-actions deployments. I would also appreciate suggestions for other relevant content if anyone has found something I have missed.

Continue reading: Noting the differences in deploying R vs Python apps on Posit Connect

Understanding the differentiation in deploying R versus Python apps on Posit Connect

The following discussion intends to delve deeper into the key points raised in an article about the experience of deploying Python and R Shiny apps onto Posit Connect via GitHub Actions. It will further elaborate on the long-term implications of these findings and speculate on the future outcomes.

Key Insights from the article

1. The initial misunderstanding was that Posit Connect can only listen to branches, potentially implying it could only publish changes from specific branches rather than a full deployment. It was later perceived that this was not completely accurate.
2. With a Python Shiny app, the rsconnect-python package was used, but it only deployed new content even in instances where there hadn’t been any changes to the manifest.json file. It was also noted that this command isn’t capable of recognizing identical content already existing on the server.
3. Conversely, for R Shiny app deployment, there exists an action provided by Posit that works better by allowing updates to existing deployments.
4. However, this R deployment methodology has its quirks, such as maintaining the renv.lock file updated. And if the app to be deployed is made using {golem}, it gets a bit complicated.
5. It was discovered that RStudio actions could be used for Python app deployment. A test done by Posit deployed a Flask app, affirming this possibility.

Long-term implications and potential future developments

The disparity in deploying Python and R Shiny apps on Posit Connect presents an opportunity for enhancement in the process and emphasizing clarity in deployment behavior. Expressly for Python app deployment, it might push the advancement of a more flexible and practical package similar to RStudio actions, particularly regarding detecting existing content.

More functionalities might be adopted from the rsconnect-ts package in the future as it appears to have a broader spectrum of flexibility. Its ability to deploy Python Shiny apps is impressive but is still at a beta stage and might be improved or better advertised in the future.

Actionable Advice

• When deploying, a comprehension of variances in deploying Python and R shiny apps on Posit Connect is crucial to minimize errors or redundancies.
• The capabilities offered by different packages should be well reviewed. For instance, rsconnect-python might not be the popular choice when updates need to be pushed to existing deployments or when preventing duplication is a priority.
• Extra attention is needed for R shiny deployments due to its quirky behavior like the necessity to update the renv.lock file.
• Exploring lesser-known packages like rsconnect-ts may offer more flexibility and functionalities, especially for Python app deployments.

Read the original article