You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a good chance that users will end with an app structure that looks like:
app.R
L R /
L this.R
L that.R
L tests/
...
L www (maybe)
This is very close to what we've got in {golem}, and I think that this should be facilitated by golem::create_golem(".").
The current implementation of this function throws a warning:
> golem::create_golem(".")
── Checking package name ───────────────────────────────────────────────────────
✔ Valid package name
The path . already exists, override?
1: Yeah
2: No way
3: Not yet
When it fact even if we say YES, the path is not really overriden: the files are copied, but the one that already existed are not deleted.
colin:plop colin$ cd /tmp && mkdir plouf && cd plouf
colin:plouf colin$ mkdir R tests www
colin:plouf colin$ touch app.R R/this.R R/that.R www/ping.css
colin:plouf colin$ ls
R app.R tests www
colin:plouf colin$ R --quiet
> golem::create_golem(".")
── Checking package name ───────────────────────────────────────────────────────
✔ Valid package name
The path . already exists, override?
1: No way
2: Yes
3: Nope
Selection: 2
── Creating dir ────────────────────────────────────────────────────────────────
✔ Created package directory
── Copying package skeleton ────────────────────────────────────────────────────
✔ Copied app skeleton
── Setting the default config ──────────────────────────────────────────────────
✔ Configured app
── Done ────────────────────────────────────────────────────────────────────────
A new golem named plouf was created at /private/tmp/plouf .
To continue working on your app, start editing the 01_start.R file.
> q()
Save workspace image? [y/n/c]: n
colin:plouf colin$ ls
DESCRIPTION R dev man www
NAMESPACE app.R inst tests
colin:plouf colin$ ls R
app_config.R app_server.R app_ui.R run_app.R that.R this.R
So, my take on that kind of app is:
We should not ask to "override" as it is not really what is done
So, I think we need to change a little bit the way
{golem}
behaves when the user chooses to build a golem in his current directory.Following the last changes in
{shiny}
, notably these two PR from @trestletech:There's a good chance that users will end with an app structure that looks like:
This is very close to what we've got in
{golem}
, and I think that this should be facilitated bygolem::create_golem(".")
.The current implementation of this function throws a warning:
When it fact even if we say YES, the path is not really overriden: the files are copied, but the one that already existed are not deleted.
So, my take on that kind of app is:
www
toinst/app/www
if it existsDESCRIPTION
file if ever it exists (and don't override it: it seems like a common thing inside the shiny example repo: https://github.com/rstudio/shiny-examples/tree/master/001-hello)usethis::use_buildignore("app.R")
if it exists.Also, this should be documented clearly (a vignette ?)
The text was updated successfully, but these errors were encountered: