Intent

Implement support for viewing execution environment runtimes.

Fixes #313

Approach

Implement an R6 class, following modified pattern from prior connectapi classes.

The class includes custom [[ and $ methods to make data properties (i.e. fields returned by Connects API) as easy as accessing methods.

Create an active binding all_runtimes to return a data frame of all runtimes.

> all_envs <- get_execution_envs(client)
> e <- all_envs[[2]]

Access "data" properties at top level.

> e$title
[1] "Custom Image Classifier"

Access other properties at top level as usual.

> e$connect
Posit Connect API Client: 
  Posit Connect Server: https://connect.example
  Posit Connect API Key: ***********ABC1
> e$data
$id
[1] "3"

$guid
[1] "5c47281b-d8ac-4386-b332-c9f78454440d"

$created_time
[1] "2024-07-09T19:09:34Z"
...

The print method currently includes the output of the env$all_runtimes active binding, since that's some of the most pertinent info.

> e
Execution Environment 
  Title: "Custom Image Classifier"
  Description: "My custom image classifier"
  Name: "myorg/myrepo/image-classifier-asdf:jammy"
  Runtimes:
# A tibble: 2 × 3
  language version path                         
  <chr>    <chr>   <chr>                        
1 r        4.2.1   /opt/R/4.2.1/bin/R           
2 python   3.8.5  /opt/python/3.8.5/bin/python

Redefining [[ and $ for this class

I initially tried an approach where each expected field had an active binding that looked up the property from $data. For example:

  active = list(
    r = self$data$r
  )

However, this approach breaks extracting sub-objects, such as in the following code, which returns NULL:

obj$r$installations

When redefining [[ and $, you can extract recursively as expected.

Another approach I considered was explicitly creating literal fields dynamically when the object was initialized. There's nothing that stops us doing this dynamically with arbitrary fields at object initialization time, but it might be better to explicitly have fields present in a class's definition for documentation reasons.

Something seems right about having the class contain basically references to other connectapi objects, the data from the server, and some methods for manipulating that data — something about that seems parsimonious to me.

I've been thinking about how to prevent possible name masking. Would probably make sense to check that the $data property does not contain any names that are in the self environment and error if that's the case.

Checklist

• Does this change update NEWS.md (referencing the connected issue if necessary)?
• Does this change need documentation? Have you run devtools::document()?