Merged: type converters, dynamic image plots, dates/datetimes, open api object schema types, multiline comments, multipart form fix

[slodge]

This replaces the previous PRs on type converters, dynamic image plots, dates/datetimes and on open api object schema types - #897 #889 #891 #892

If these changes were ever to go ahead, there's a heap of documentation and some tests to sort out... but that's for future consideration.

Current manual test app:

#
# This is a Plumber API. You can run the API by clicking
# the 'Run API' button above.
#
# Find out more about building APIs with Plumber here:
#
#    https://www.rplumber.io/
#

devtools::load_all()

library(tidyverse)

#* @apiTitle Plumber Example API
#* @apiDescription Plumber example description.


#* Echo back the input
#* @param msg The message to echo
#* @get /echo
function(msg = "") {
  list(msg = paste0("The message is: '", msg, "'"))
}

#* Plot a histogram
#* @serializer png
#* @get /plot
function() {
  rand <- rnorm(100)
  hist(rand)
}

#* Return the sum of two numbers
#* @param a:int The first number to add
#* @param b:int The second number to add
#* @get /sum
function(a, b) {
  message("/sum processing a:", a, " of class ", class(a), " and b:", b, " of class ", class(b))
  a + b
}


#* Return the sum of two sets of numbers
#* @param a:[float] The first set of numbers to add
#* @param b:[float] The second set of numbers to add
#* @get /sumAll
function(a, b) {
  message("/sumAll processing a:", a, " of class ", class(a), " and b:", b, " of class ", class(b))
  sum(a, b)
}

#* Return a filtered set of strings
#* @param a:[logical] The filter map
#* @param b:[string] The set of string to filter
#* @get /filterText
function(a, b) {
  browser()
  message("/filterText processing a:", a, " of class ", class(a), " and b:", b, " of class ", class(b))
  b[a]
}

#* Is this working?
#* @param yes:bool Yes?
#* @get /boolTest
function(yes) {
  browser()
  if (yes) {
    "YES!"
  } else {
    "How sad.."
  }
}

#* @param when:date the date
#* @param t:date-time The date and time
#* @get /dates
function(when, t) {

  browser()
  paste0("The date was ", when, " and the time was ", t)
}

#* Do something
#* @post /doIt
#* @requestBody ARequestThing
#* @response 200 @body AResponseThing The success response
function(req) {
  browser()
  req$body
}

#* This is an object
#* @schema ARequestThing
#* @prop first:string The filter map
#* @prop a:[logical] The filter map
#* @prop b:[string] The set of string to filter
NULL

#* This is an object
#* @schema AResponseThing
#* @prop life:string Just a description
#* @prop details:[object]:AResponseSubThing This gets advanced
NULL

#* This is an object
#* @schema AResponseSubThing
#* @prop id:int Just a description
#* @prop value:string More descriptions
NULL

#* Plot out data from the iris dataset
#* @param spec If provided, filter the data to only this species (e.g. 'setosa')
#* @get /plot
#* @serializer png
function(spec = "setosa"){
  myData <- iris
  title <- "All Species"

  # Filter if the species was specified
  if (!missing(spec)){
    title <- paste0("Only the '", spec, "' Species")
    myData <- subset(iris, Species == spec)
  }

  plot(myData$Sepal.Length, myData$Petal.Length,
       main=title, xlab="Sepal Length", ylab="Petal Length")
}

#* Sort letters
#* @param letters:[string]
#* @serializer json
#* @get /letters/<letters:[string]>
function(letters) {
  sort(letters)
}

renders and runs as:

[taylo5jm]

@slodge Thanks for your work on the schemas -- I'm very interested in using this functionality. Is there a way to mark the schema properties as required? Also, anyone here able to give a general status update on this PR? I'm curious when these features might be available. Thanks!

[slodge]

It looks like I include a line:

      required <- identical(propMat[1,6], "*")

So if you try

#* This is an object
#* @schema ARequestThing
#* @prop first:string* A first property
NULL

then that should hopefully give you a required flag in the spec for first... (not tested this but looks like all the code is there!)

---

I have no info on when/if any of this will make it into a plumber release. I don't believe there is anyone actively committing any time to plumber within Posit at present, and the team indicated that they won't accept these PR features until they've implemented some new "edition"-based versioning code - so I don't see this happening "soon".

[taylo5jm]

@slodge Awesome. The * works for me!

Thanks for sharing the status of this PR. The "Schema Object" seems to be a useful component of the OpenAPI Specification (at least in version 3.1.0), so it would be great to see this functionality in plumber.

@schloerke Are you able to provide more color around the issues blocking this PR in terms of timelines?

[slodge]

@schloerke @taylo5jm is there any kind of timeline for when someone at Posit might give plumber some attention? If we're waiting on "editions" before accepting new functionality, is there a design or draft PR for those so others can assist getting them built?

[JosiahParry]

I just wanted to follow up on this PR. It would be great to have.

[JosiahParry]

I suspect that this PR is too large to merge? Is there a suggested path forward for us to have argument type specification and parsing without having to manually cast inside the body of functions?

[slodge]

The team haven't had time to work on this nor on the previous smaller PRs - but I do get periodic assurances they are keen to work on things and they are hopeful to get something integrated soon. From what they said before (December 2022) I think they want to implement a new versioning scheme before they accept any new functionality - this seems sensible, but I don't know any timeline on that. You can still see the smaller PRs in closed PRs here - your welcome to reinstate them, but I'd check with posit on their availability and plans before investing too much effort 👍 Alternatively, it looks increasingly like FastApi might be a good route to consider - that has ongoing development and good support in Connect.

…

On Tue, 7 Nov 2023, 21:39 Josiah Parry, ***@***.***> wrote: I suspect that this PR is too large to merge? Is there a suggested path forward for us to have argument type specification and parsing without having to manually cast inside the body of functions? — Reply to this email directly, view it on GitHub <#905 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAECJHTZJGTEIVFENGOXQQLYDKTCVAVCNFSM6AAAAAAVEUN4USVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBQGIYDQOBSGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JosiahParry]

@slodge thanks! FastAPI is a python library and out of scope of my interest :)

[slodge]

I think this is the smaller PR you are interested in - #889 We closed it because it was too much effort maintaining multiple long-running feature branches for us internally.

…

On Tue, 7 Nov 2023, 22:05 Stuart Lodge, ***@***.***> wrote: The team haven't had time to work on this nor on the previous smaller PRs - but I do get periodic assurances they are keen to work on things and they are hopeful to get something integrated soon. From what they said before (December 2022) I think they want to implement a new versioning scheme before they accept any new functionality - this seems sensible, but I don't know any timeline on that. You can still see the smaller PRs in closed PRs here - your welcome to reinstate them, but I'd check with posit on their availability and plans before investing too much effort 👍 Alternatively, it looks increasingly like FastApi might be a good route to consider - that has ongoing development and good support in Connect. On Tue, 7 Nov 2023, 21:39 Josiah Parry, ***@***.***> wrote: > I suspect that this PR is too large to merge? Is there a suggested path > forward for us to have argument type specification and parsing without > having to manually cast inside the body of functions? > > — > Reply to this email directly, view it on GitHub > <#905 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAECJHTZJGTEIVFENGOXQQLYDKTCVAVCNFSM6AAAAAAVEUN4USVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBQGIYDQOBSGY> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
2 out of 3 committers have signed the CLA.

✅ slodge
✅ schloerke
❌ slodge-work
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[slodge]

Notes from #911 also merged

[slodge]

As discussed in #920 this PR is too large and complex to merge.

Respectfully closing.