Deprecate `quarto_publish_*()` in favour of rsconnect functions

[hadley]

Now that rsconnect provides a friendlier UI. Please feel free to ping me in you think there's anything missing in rsconnect that I can add.

[cderv]

So I have been looking into this by comparins current status of what has been done for quarto_publish_* function and what is available through rsconnect

General

Function in this package does make use of rsconnect and wrap the usage, by adding a bit more quarto specifics

Main differences are that quarto_publish_* allows rendering first locally before publishing. I don't think rsconnect allows this mode.

quarto_publish_doc()

• title will be retrieved from document metadata to pass as appTitle. This makes is more customised once deployed (otherwise filename is used I think)
  

  quarto-r/R/publish.R

  Lines 75 to 78 in 62c0eb7

  	# determine title
  	if (is.null(title)) {
  	title <- input_formats[[format]]$metadata$title
  	}

• It allows publishing to RPubs by wrapping rsconnect::rpubsUpload(), also using the title available in document meta

• resources metadata is considered for explicit resources to include in the deployed bundle.
  

  quarto-r/R/publish.R

  Lines 45 to 48 in 62c0eb7

  	# get metadata
  	inspect <- quarto_inspect(input)
  	input_formats <- inspect[["formats"]]
  	resources <- inspect[["resources"]]

  
  I believe this is a new support to add to rmarkdown::find_external_resources() that is used in rsconnect

quarto_publish_app()

The function will supply appPrimaryDoc for some specific use case where non standard index.qmd is used.

quarto-r/R/publish.R

Lines 265 to 294 in 62c0eb7

	find_app_primary_doc <- function(dir) {
	preferred <- c(
	"index.Rmd",
	"index.rmd",
	"index.qmd",
	"ui.Rmd",
	"ui.rmd",
	"ui.qmd"
	)
	preferred <- preferred[file.exists(file.path(dir, preferred))]
	if (length(preferred) > 0) {
	return(preferred[[1]])
	} else {
	all_docs <- list.files(path = dir, pattern = "^[^_].*\\.[Rrq][Mm][Dd]$")
	if (length(all_docs) == 1) {
	return(all_docs)
	} else {
	primary_doc <- NULL
	for (doc in all_docs) {
	yaml <- rmarkdown::yaml_front_matter(file.path(dir, doc))
	if (is_shiny_prerendered(yaml[["runtime"]], yaml[["server"]])) {
	primary_doc <- doc
	break
	}
	}
	return(primary_doc)
	}
	}
	return(NULL)
	}

So it seems a little more specific than what rsconnect is doing. Really specific way to create shiny apps with Quarto though

quarto_publish_site

• title will be infered from configuration by looking in inspect
  

  quarto-r/R/publish.R

  Lines 217 to 227 in 62c0eb7

  	# get metadata
  	inspect <- quarto_inspect(input)
  	config <- inspect[["config"]]
  	# render if requested
  	if (render == "local") {
  	quarto_render(input, as_job = FALSE)
  	}
  	# title
  	title <- config$site[["title"]]

• It supports deploying only the output site, by rendering locally, and deploying output-dir

Conclusion

Do we want to be more specific in rsconnect to support what the current functions are supporting?

We also have quarto publish for which there is no wrapper R function yet

• quarto publish wrapper  #101

I plan to add one, because it brings support for quartopub publishing too.

This is why I am wondering if the function should really be deprecated, or kept with theme for them specific Quarto support, before calling rsconnect functions.

Did you look at these differences and choose not to support them? Or could we try to add this specific support in rsconnect directly?
Keeping the quarto_publish_* wrapper is also an option

[hadley]

I don't have super strong feelings here, except that we should consider the publishing ecosystem holistically, rather than building a bunch of disparate pieces that don't fit together.

[cderv]

Yeah, I understand. I am ok to PR into rsconnect to bring the specific Quarto support we have here.
Would that be ok? This way, we could remove those functions here.

Regarding quarto publish, it has some providers that rsconnect does not support, and probably won't. So we can't really merge this piece into another one, except maybe for working on a more generic CLI tool different from R / Python packages.

[hadley]

Sounds good to me.