-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
generate title and name; name is normalized #1023
base: main
Are you sure you want to change the base?
Conversation
CI failures due to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we do something to generateAppName()
to make it less likely to make this mistake again?
I considered modifying Open to suggestions. |
Maybe we should deprecate it. It is public, but I doubt many people are using it. There's no evidence of another CRAN package using it: https://github.com/search?q=org%3Acran%20generateAppName&type=code. But maybe it's used by the IDE? |
The IDE calls |
@hadley Given #1022 (comment), how do we want
We cannot modify The best answer would be to use the incoming filename to generate a title alongside the name, which needs less normalization, and then normalize only the name. I considered this option but abandoned it because it felt like too much of a change for what felt like a bug fix. I'm leaning towards having |
Yeah, letting |
OK. I'll take a stab at that and update this PR. |
f4986a9
to
019920f
Compare
019920f
to
e2236c2
Compare
@@ -91,7 +91,13 @@ findDeploymentTarget <- function( | |||
# Otherwise, identify a target account (given just one available or prompted | |||
# by the user), generate a name, and locate the deployment. | |||
accountDetails <- findAccountInfo(account, server, error_call = error_call) | |||
appName <- generateAppName(appTitle, recordPath, accountDetails$name, unique = FALSE) | |||
appTitle <- generateTitle(recordPath = recordPath, title = appTitle) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has the side-effect of generating an appTitle
for shinyapps.io content, which does not support title. Alternatively, we could generate a title only for Connect deployments.
The other drawback of this approach is that as soon as we have generated the title, we lose track of the fact that the title was not user-specified. This means that the generated title will always overwrite the deployment record title.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to distinguish between "user provided title" and "generated title" when updating a discovered deployment record.
title <- userTitle %||% deployment$title %||% generatedTitle
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After more testing, we probably want to avoid generating titles for shinyapps.io.
The IDE deployment pane forces a normalized "title", which becomes the title and name:
After manually normalizing the title with "incredible-shiny-application" and completing this workflow, the deployment record name and title both receive the same value (as forced by the IDE).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the CRAN version of rsconnect::deployApp()
leaves a shinyapps.io deployment record with title=NULL
. The IDE deployment workflow creates deployment records with title and name both with the same value.
The IDE allows mixed-case names(titles) for shinyapps.io, but mixed-case is not produced by generateAppName()
.
@@ -98,7 +98,7 @@ saveDeployment <- function(recordDir, | |||
addToHistory = TRUE) { | |||
deployment <- deploymentRecord( | |||
name = deployment$name, | |||
title = deployment$title, | |||
title = application$title %||% deployment$title, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This helps make sure that a server-updated title is reflected on the client.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to take this change even if we decide to abandon the other name-generation aspects of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How will automatically generating a title interact with this? Will auto-generated titles overwrite titles that have been changed on Connect?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't feel like I have a completely clear picture of some of the effects of this change. Open questions for me are around how these changes interact with titles that have been updated on Connect.
Prior to this update, the default title was an empty string. Now, if we aren't provided a title, we generate one, and use this to generate a name. Will this overwrite titles that have been changed on Connect?
How does this interact with deployment records? It looks like we get titles from deployment records (see here). Will this lead to a title that has been changed on Connect reverting to the previously-published title when it is updated? (Outside of the scope of these changes, but a question raised by them.)
The pre-1.0.0 behavior was to use a non-lowercased appName
, right? Perhaps better to revert to that, and only use appTitle
if provided.
@@ -98,7 +98,7 @@ saveDeployment <- function(recordDir, | |||
addToHistory = TRUE) { | |||
deployment <- deploymentRecord( | |||
name = deployment$name, | |||
title = deployment$title, | |||
title = application$title %||% deployment$title, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How will automatically generating a title interact with this? Will auto-generated titles overwrite titles that have been changed on Connect?
When deploying from a directory named "Incredible Shiny Application", the generated name for Posit Connect isIncredible_Shiny_Application
and for shinyapps.io isincredible_shiny_application
. Both services requirea-zA-Z0-9-_
for names, but we lower-case only for shinyapps.io.The name is derived from an incoming title, when available, and otherwise from the content path.When deploying without a title, Connect uses the incoming name to seed the title. This behavior is not changing.When deploying from a directory named "Incredible Shiny Application", a generated title mirrors the directory name and name is generated from the title and normalized like
incredible_shiny_application
.A generated name is used only when one is not already provided.
Title changes on the server are now reflected in the deployment record.
fixes #1022
related to #1008