Merge branch 'main' into rc-v1.2.2

DESCRIPTION

@@ -32,8 +32,7 @@ Imports:
     magrittr,
     mime,
     lifecycle (>= 0.2.0),
-    ellipsis (>= 0.3.0),
-    rlang
+    rlang (>= 1.0.0)
 ByteCompile: TRUE
 Suggests:
     testthat (>= 0.11.0),
@@ -54,7 +53,7 @@ Suggests:
     redoc,
     rapidoc,
     sf
-RoxygenNote: 7.3.1
+RoxygenNote: 7.3.2
 Collate:
     'async.R'
     'content-types.R'

R/options_plumber.R

@@ -68,7 +68,7 @@ options_plumber <- function(
   sharedSecret         = getOption("plumber.sharedSecret"),
   legacyRedirects      = getOption("plumber.legacyRedirects")
 ) {
-  ellipsis::check_dots_empty()
+  rlang::check_dots_empty()
 
   # Make sure all fallback options are disabled
   if (!missing(docs.callback) && is.null(docs.callback)) {

R/plumber.R

@@ -173,7 +173,7 @@ Plumber <- R6Class(
         stop("Plumber router `$run()` method should not be called while `plumb()`ing a file")
       }
 
-      ellipsis::check_dots_empty()
+      rlang::check_dots_empty()
 
       # Legacy support for RStudio pro products.
       # Checks must be kept for >= 2 yrs after plumber v1.0.0 release date

R/pr.R

@@ -528,7 +528,7 @@ pr_run <- function(pr,
                    quiet = FALSE
 ) {
   validate_pr(pr)
-  ellipsis::check_dots_empty()
+  rlang::check_dots_empty()
   pr$run(host = host,
          port = port,
          debug = debug,

README.md

@@ -107,7 +107,7 @@ will be the best way to get started. You'll be able to get a server hosting your
 custom API in just two R commands. To deploy to DigitalOcean, check out the
 `plumber` companion package [`plumberDeploy`](https://github.com/meztez/plumberDeploy).
 
-[RStudio Connect](https://posit.co/products/enterprise/connect/) is a commercial
+[Posit Connect](https://posit.co/products/enterprise/connect/) is a commercial
 publishing platform that enables R developers to easily publish a variety of R
 content types, including Plumber APIs. Additional documentation is available at
 https://www.rplumber.io/articles/hosting.html#rstudio-connect-1.

vignettes/routing-and-input.Rmd

@@ -228,15 +228,15 @@ HTTP requests in Plumber are stored as environments and satisfy the [Rook interf
 Name | Example | Description
 ---- | ------- | -----------------------
 `pr` | `plumber::pr()` | The Plumber router that is processing the request
-`cookies` | `list(cook="abc")` | A list of the cookies as described in [Cookies](#read-cookies)
+`cookies` | `list(cook = "abc")` | A list of the cookies as described in [Cookies](#read-cookies)
 `httpuv.version` | `"1.3.3"` | The version of the underlying [`httpuv` package](https://github.com/rstudio/httpuv)
 `PATH_INFO` | `"/"` | The path of the incoming HTTP request
 `bodyRaw` | `charToRaw("a=1&b=2")` | The `raw()`, unparsed contents of the body of the request
-`body` | `list(a=1,b=2)` | This value will typically be the same as `argsBody`.  However, with content type `"multipart/*"`, `req$body` may contain detailed information, such as `name`, `content_type`, `content_disposition`, `filename`, `value` (which is a `raw()` vector), and `parsed` (parsed version of `value`).
-`argsBody` | `list(a=1,b=2)` | The parsed body output. Typically this is the same as `req$body` except when type is `"multipart/*"`.
-`argsPath` | `list(c=3,d=4)` | The values of the path arguments.
-`argsQuery` | `list(e=5,f=6)` | The parsed query string output.
-`args` | `list(req=req,res=res,e=5,f=6,c=3,d=4,a=1,b=2)` | In a route, the combined arguments of `list(req = req, res = res)`, `req$args` (added by filters), `req$argsQuery`, `req$argsPath`, and `req$argsBody`. In a filter, `req$args` is initialized to an empty list, so when processing filters `req$args` will only contain arguments set by previously processed filters as the route information will not have been processed yet.
+`body` | `list(a = 1, b = 2)` | This value will typically be the same as `argsBody`.  However, with content type `"multipart/*"`, `req$body` may contain detailed information, such as `name`, `content_type`, `content_disposition`, `filename`, `value` (which is a `raw()` vector), and `parsed` (parsed version of `value`).
+`argsBody` | `list(a = 1, b = 2)` | The parsed body output. Typically this is the same as `req$body` except when type is `"multipart/*"`.
+`argsPath` | `list(c = 3, d = 4)` | The values of the path arguments.
+`argsQuery` | `list(e = 5, f = 6)` | The parsed query string output.
+`args` | `list(req = req, res = res, e = 5, f = 6, c = 3, d = 4, a = 1, b = 2)` | In a route, the combined arguments of `list(req = req, res = res)`, `req$args` (added by filters), `req$argsQuery`, `req$argsPath`, and `req$argsBody`. In a filter, `req$args` is initialized to an empty list, so when processing filters `req$args` will only contain arguments set by previously processed filters as the route information will not have been processed yet.
 `QUERY_STRING` | `"?a=123&b=abc"` | The query-string portion of the HTTP request
 `REMOTE_ADDR` | `"1.2.3.4"` | The IP address of the client making the request
 `REMOTE_PORT` | `"62108"` | The client port from which the request originated
@@ -303,7 +303,7 @@ Running `curl --data "id=123&name=Jennifer" "http://localhost:8000/user"` will r
 ```{r, echo=FALSE, results='asis'}
 r <- plumber::plumb("files/apis/03-04-body.R")
 e <- r$endpoints[[1]][[1]]
-code_chunk(json_serialize(e$exec(req=list(bodyRaw = charToRaw("id=123&name=Jennifer"), body=list(id = 123, name = "Jennifer"), args = list(id = 123, name = "Jennifer")), res = NULL)), "json")
+code_chunk(json_serialize(e$exec(req = list(bodyRaw = charToRaw("id=123&name=Jennifer"), body = list(id = 123, name = "Jennifer"), args = list(id = 123, name = "Jennifer")), res = NULL)), "json")
 ```
 
 Alternatively, `echo {"id":123, "name": "Jennifer"} > call.json & curl --data @call.json "http://localhost:8000/user" -H "content-type: application/json"` (formatting the body as JSON) will have the same effect.
@@ -342,7 +342,7 @@ HTTP headers attached to the incoming request are attached to the request object
 Running `curl --header "customheader: abc123" http://localhost:8000` will return:
 
 ```{r, echo=FALSE, results='asis'}
-code_chunk(json_serialize(list(val="abc123")), "json")
+code_chunk(json_serialize(list(val = "abc123")), "json")
 ```
 
 You can print out the names of all of the properties attached to the request by running `print(ls(req))` inside an endpoint.