date:20240104

Re: [R-pkg-devel] Assigning an object to the global environment (shiny package)

2024-01-04 Thread Tiago Olivoto

Dear all,
Thanks all for the tips and sorry for the automatic reply.
Best regards,
Olivoto

Em qui., 4 de jan. de 2024 às 18:00, Iris Simmons 
escreveu:

> You cannot and should not ignore this.
>
> An R package should never ever be assigning variables into environments
> for which they haven't been granted permission to do so. You should ask the
> user whether they want the object assigned in the global environment before
> doing so, and the default should be no so that it will not be assigned in
> non interactive sessions.
>
> On Thu, Jan 4, 2024, 15:54 Tiago Olivoto  wrote:
>
>> Hi everyone!
>> I which a happy new year!
>>
>>
>> I'm coding a shiny app and I would like to include an option so that the
>> users can assign the results to the global environment for further
>> analysis.
>>
>> I have written the following code, which checks if 'globalvarname' (the
>> name of object to be created in the global environment) already exists,
>> returning an error if so, and asking to the user change the name.
>>
>> code
>> ---
>> observeEvent(input$savetoglobalenv, {
>>  ### more code here
>>
>>   if (exists(input$globalvarname, envir = globalenv())) {
>> sendSweetAlert(
>>   session = session,
>>   title = "Error",
>>   text = paste0("The object'", input$globalvarname, "' already exists
>> in the global environment. Please, change the name."),
>>   type = "success"
>> )
>>   } else {
>> assign(input$globalvarname, report, envir = globalenv())
>> ask_confirmation(
>>   inputId = "myconfirmation",
>>   type = "warning",
>>   title = "Close the App?",
>>   text = paste0("The object'", input$globalvarname, "' has been
>> created
>> in the Global environment. To access the created object, you need first to
>> stop the App. Do you really want to close the app now?"),
>>   btn_labels = c("Nope", "Yep"),
>>   btn_colors = c("#FE642E", "#04B404")
>> )
>>   }
>> })
>> -
>>
>> Thus, the object is only created when the user decides to assign such an
>> object to the global environment. As the object's name is checked, there
>> is
>> no way of replacing some object already available in the global
>> environment.
>>
>> Of course, when running devtools::check(), a NOTE is returned
>>
>> Found the following assignments to the global environment:
>>   Arquivo 'plimanshiny/R/mod_analyze.R':
>>
>> Can I ignore this safely?
>> Is there any suggestion to handly this without using 'assign()'
>>
>> Thanks in advance,
>> Olivoto
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [Rd] static html vignette

2024-01-04 Thread Adrian Dușa

On Thu, Jan 4, 2024 at 10:44 PM Uwe Ligges 
wrote:

> On 04.01.2024 21:23, Duncan Murdoch wrote:[...]
> > Users aren't forced to install "Suggests" packages.  That's a choice
> > they make.  The default for `install.packages()` is `dependencies = NA`,
> > which says to install hard dependencies (Imports, Depends, LinkingTo).
> > Users have to choose a non-default setting to include Suggests.
>
> Also note that the maintainer builds the vignette whe calling
> R CMD build
> CRAN checks whether the vignette can be build.
> If a user installs a package, the already produced vignette (on the
> maintainers machine by R CMD build) is instaled. There is no need for
> the user to install any extra package for being able to look at the
> vignettes.
>

I see... then I must have tested with dependencies = TRUE thinking this
refers to hard dependencies (one more reason to read the documentation
properly).

Thank you,
Adrian

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Assigning an object to the global environment (shiny package)

2024-01-04 Thread Josiah Parry

Alternatively, you can create a new environment in your package and assign
into it and fetch out of it. This is definitely safer and probably "more
idiomatic." Hope that helps!


# create a new environment
my_env
<- rlang::new_environment()

#
assign a value to the environment
rlang::env_bind(my_env,
var_name = "my value")

#
fetch the value from the environment
my_env$var_name
#>
[1] "my value"


On Thu, Jan 4, 2024 at 4:04 PM Iris Simmons  wrote:

> You cannot and should not ignore this.
>
> An R package should never ever be assigning variables into environments for
> which they haven't been granted permission to do so. You should ask the
> user whether they want the object assigned in the global environment before
> doing so, and the default should be no so that it will not be assigned in
> non interactive sessions.
>
> On Thu, Jan 4, 2024, 15:54 Tiago Olivoto  wrote:
>
> > Hi everyone!
> > I which a happy new year!
> >
> >
> > I'm coding a shiny app and I would like to include an option so that the
> > users can assign the results to the global environment for further
> > analysis.
> >
> > I have written the following code, which checks if 'globalvarname' (the
> > name of object to be created in the global environment) already exists,
> > returning an error if so, and asking to the user change the name.
> >
> > code
> > ---
> > observeEvent(input$savetoglobalenv, {
> >  ### more code here
> >
> >   if (exists(input$globalvarname, envir = globalenv())) {
> > sendSweetAlert(
> >   session = session,
> >   title = "Error",
> >   text = paste0("The object'", input$globalvarname, "' already exists
> > in the global environment. Please, change the name."),
> >   type = "success"
> > )
> >   } else {
> > assign(input$globalvarname, report, envir = globalenv())
> > ask_confirmation(
> >   inputId = "myconfirmation",
> >   type = "warning",
> >   title = "Close the App?",
> >   text = paste0("The object'", input$globalvarname, "' has been
> created
> > in the Global environment. To access the created object, you need first
> to
> > stop the App. Do you really want to close the app now?"),
> >   btn_labels = c("Nope", "Yep"),
> >   btn_colors = c("#FE642E", "#04B404")
> > )
> >   }
> > })
> > -
> >
> > Thus, the object is only created when the user decides to assign such an
> > object to the global environment. As the object's name is checked, there
> is
> > no way of replacing some object already available in the global
> > environment.
> >
> > Of course, when running devtools::check(), a NOTE is returned
> >
> > Found the following assignments to the global environment:
> >   Arquivo 'plimanshiny/R/mod_analyze.R':
> >
> > Can I ignore this safely?
> > Is there any suggestion to handly this without using 'assign()'
> >
> > Thanks in advance,
> > Olivoto
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [Rd] static html vignette

2024-01-04 Thread Josiah Parry

I understand that this doesn't actually *solve *your problem, but would
like to offer an alternative perspective.

I often find that vignettes may be most useful as an extended form of
documentation. If you have a pkgdown site, you can use
`usethis::use_article()` to create an article which will not be included as
part of the package itself but will be served in the documentation site of
the package. I don't think many people consume extended package
documentation through vignettes all that much but often prefer to rely on
the package website. Using the article format means that your package tests
on CRAN will not be subjected to any other packages used in the articles or
vignettes.

Cheers!

On Thu, Jan 4, 2024 at 3:44 PM Uwe Ligges 
wrote:

>
>
> On 04.01.2024 21:23, Duncan Murdoch wrote:
> > On 04/01/2024 11:43 a.m., Adrian Dușa wrote:
> >  > (Moved here following Ivan's suggestion)
> >  >
> >  > On Thu, Jan 4, 2024 at 12:55 PM Ivan Krylov 
> > wrote:
> >  >
> >  >> On Thu, 4 Jan 2024 11:57:15 +0200
> >  >> Adrian Dușa  wrote:
> >  >>
> >  >>> I wonder if it would be possible to include an html static vignette.
> >  >>
> >  >> I would say that static vignettes are against the spirit of
> vignettes:
> >  >> the idea is to provide another layer of unit testing to the package
> by
> >  >> providing a deeper executable example than is possible with just Rd
> >  >> examples. I think that Bioconductor will even refuse a package with a
> >  >> vignette with no executable code in it.
> >  >>
> >  >
> >  > I understand that perfectly, but for instance my package declared
> > already
> >  > has over 800 tests and 100% code coverage. More unit testing in the
> >  > vignettes really strikes as unnecessary.
> >  >
> >  > One other reason to use a static vignette, in my case, is that package
> >  > Sweave is not available for my version of R (on MacOS, M2 version)
> > As far as I know, there is no package called Sweave, there's just the
> > Sweave() function in the utils package.>
> >  >
> >  >
> >  >> Still, you can ue the R.rsp package to provide static vignettes in
> >  >> both PDF and HTML formats:
> >  >>
> >  >>
> >
> https://cran.r-project.org/package=R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf
> >  >>
> >  >> This will add 6 packages to your total Suggests budget:
> >  >>
> >  >> setdiff(
> >  >>   unlist(package_dependencies('R.rsp', recursive=TRUE)),
> >  >>   unlist(standard_package_names())
> >  >> )
> >  >> # [1] "R.methodsS3" "R.oo""R.utils" "R.cache"
> "digest"
> >  >
> >  >
> >  > Yes indeed, I know about R.rsp.
> >  > To me at least, zero dependency means that users install that package
> > and
> >  > that package alone, the reason for which I am now looking for static
> >  > (preferably html) vignettes.
> >  >
> >  > I guess another question is why should the "Suggests" packages need
> > to be
> >  > installed by end users. I understand CRAN checks need to make sure the
> >  > Vignettes can be processed and the code inside runs fine (just like
> the
> >  > examples in the Rd files) but it is very unlikely that end-users will
> > want
> >  > to compile the vignettes themselves.
> >  >
> >  >  From my own experience of almost 20 years of using R, I never-ever
> > build
> >  > the vignettes of a certain package because it is much simpler to read
> > them
> >  > on CRAN. I wonder, then, why are end users forced to install
> >  > Vignette-building "Suggests" packages (with long dependency chains)
> when
> >  > they practically never do that.
> >  >
> >  > Life would be much simpler if the Suggests packages would not be
> >  > (automatically) installed, or if CRAN provided a way to include static
> >  > Vignettes to avoid the heavy dependencies of building them.
> >  >
> > Users aren't forced to install "Suggests" packages.  That's a choice
> > they make.  The default for `install.packages()` is `dependencies = NA`,
> > which says to install hard dependencies (Imports, Depends, LinkingTo).
> > Users have to choose a non-default setting to include Suggests.
>
> Also note that the maintainer builds the vignette whe calling
> R CMD build
> CRAN checks whether the vignette can be build.
> If a user installs a package, the already produced vignette (on the
> maintainers machine by R CMD build) is instaled. There is no need for
> the user to install any extra package for being able to look at the
> vignettes.
>
> Best,
> Uwe Ligges
>
>
>
>
> >
> > Duncan Murdoch
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Assigning an object to the global environment (shiny package)

2024-01-04 Thread Duncan Murdoch


On 04/01/2024 3:51 p.m., Tiago Olivoto wrote:

Hi everyone!
I which a happy new year!


I'm coding a shiny app and I would like to include an option so that the
users can assign the results to the global environment for further analysis.

I have written the following code, which checks if 'globalvarname' (the
name of object to be created in the global environment) already exists,
returning an error if so, and asking to the user change the name.

code
---
observeEvent(input$savetoglobalenv, {
  ### more code here

   if (exists(input$globalvarname, envir = globalenv())) {
 sendSweetAlert(
   session = session,
   title = "Error",
   text = paste0("The object'", input$globalvarname, "' already exists
in the global environment. Please, change the name."),
   type = "success"
 )
   } else {
 assign(input$globalvarname, report, envir = globalenv())
 ask_confirmation(
   inputId = "myconfirmation",
   type = "warning",
   title = "Close the App?",
   text = paste0("The object'", input$globalvarname, "' has been created
in the Global environment. To access the created object, you need first to
stop the App. Do you really want to close the app now?"),
   btn_labels = c("Nope", "Yep"),
   btn_colors = c("#FE642E", "#04B404")
 )
   }
})
-

Thus, the object is only created when the user decides to assign such an
object to the global environment. As the object's name is checked, there is
no way of replacing some object already available in the global environment.

Of course, when running devtools::check(), a NOTE is returned

Found the following assignments to the global environment:
   Arquivo 'plimanshiny/R/mod_analyze.R':

Can I ignore this safely?
Is there any suggestion to handly this without using 'assign()'


A simple alternative would be to assign it into a private environment 
managed by your app, and supply a function to the user to retrieve it 
from there.  The user can choose where to assign the result of that 
function.


So instead of:

  user says to save to "myvar"
  you save to myvar
  user uses myvar

you would have

  user says to save value
  you save it privately
  user runs myvar <- savedvalue()

If your app requires users to be able to save several different values, 
the user could enter a name on the first line and enter it again on the 
third line.


Duncan Murdoch

Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Assigning an object to the global environment (shiny package)

2024-01-04 Thread Iris Simmons

You cannot and should not ignore this.

An R package should never ever be assigning variables into environments for
which they haven't been granted permission to do so. You should ask the
user whether they want the object assigned in the global environment before
doing so, and the default should be no so that it will not be assigned in
non interactive sessions.

On Thu, Jan 4, 2024, 15:54 Tiago Olivoto  wrote:

> Hi everyone!
> I which a happy new year!
>
>
> I'm coding a shiny app and I would like to include an option so that the
> users can assign the results to the global environment for further
> analysis.
>
> I have written the following code, which checks if 'globalvarname' (the
> name of object to be created in the global environment) already exists,
> returning an error if so, and asking to the user change the name.
>
> code
> ---
> observeEvent(input$savetoglobalenv, {
>  ### more code here
>
>   if (exists(input$globalvarname, envir = globalenv())) {
> sendSweetAlert(
>   session = session,
>   title = "Error",
>   text = paste0("The object'", input$globalvarname, "' already exists
> in the global environment. Please, change the name."),
>   type = "success"
> )
>   } else {
> assign(input$globalvarname, report, envir = globalenv())
> ask_confirmation(
>   inputId = "myconfirmation",
>   type = "warning",
>   title = "Close the App?",
>   text = paste0("The object'", input$globalvarname, "' has been created
> in the Global environment. To access the created object, you need first to
> stop the App. Do you really want to close the app now?"),
>   btn_labels = c("Nope", "Yep"),
>   btn_colors = c("#FE642E", "#04B404")
> )
>   }
> })
> -
>
> Thus, the object is only created when the user decides to assign such an
> object to the global environment. As the object's name is checked, there is
> no way of replacing some object already available in the global
> environment.
>
> Of course, when running devtools::check(), a NOTE is returned
>
> Found the following assignments to the global environment:
>   Arquivo 'plimanshiny/R/mod_analyze.R':
>
> Can I ignore this safely?
> Is there any suggestion to handly this without using 'assign()'
>
> Thanks in advance,
> Olivoto
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Assigning an object to the global environment (shiny package)

2024-01-04 Thread Tiago Olivoto

Hi everyone!
I which a happy new year!


I'm coding a shiny app and I would like to include an option so that the
users can assign the results to the global environment for further analysis.

I have written the following code, which checks if 'globalvarname' (the
name of object to be created in the global environment) already exists,
returning an error if so, and asking to the user change the name.

code
---
observeEvent(input$savetoglobalenv, {
 ### more code here

  if (exists(input$globalvarname, envir = globalenv())) {
sendSweetAlert(
  session = session,
  title = "Error",
  text = paste0("The object'", input$globalvarname, "' already exists
in the global environment. Please, change the name."),
  type = "success"
)
  } else {
assign(input$globalvarname, report, envir = globalenv())
ask_confirmation(
  inputId = "myconfirmation",
  type = "warning",
  title = "Close the App?",
  text = paste0("The object'", input$globalvarname, "' has been created
in the Global environment. To access the created object, you need first to
stop the App. Do you really want to close the app now?"),
  btn_labels = c("Nope", "Yep"),
  btn_colors = c("#FE642E", "#04B404")
)
  }
})
-

Thus, the object is only created when the user decides to assign such an
object to the global environment. As the object's name is checked, there is
no way of replacing some object already available in the global environment.

Of course, when running devtools::check(), a NOTE is returned

Found the following assignments to the global environment:
  Arquivo 'plimanshiny/R/mod_analyze.R':

Can I ignore this safely?
Is there any suggestion to handly this without using 'assign()'

Thanks in advance,
Olivoto

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [Rd] static html vignette

2024-01-04 Thread Uwe Ligges




On 04.01.2024 21:23, Duncan Murdoch wrote:

On 04/01/2024 11:43 a.m., Adrian Dușa wrote:
 > (Moved here following Ivan's suggestion)
 >
 > On Thu, Jan 4, 2024 at 12:55 PM Ivan Krylov  
wrote:

 >
 >> On Thu, 4 Jan 2024 11:57:15 +0200
 >> Adrian Dușa  wrote:
 >>
 >>> I wonder if it would be possible to include an html static vignette.
 >>
 >> I would say that static vignettes are against the spirit of vignettes:
 >> the idea is to provide another layer of unit testing to the package by
 >> providing a deeper executable example than is possible with just Rd
 >> examples. I think that Bioconductor will even refuse a package with a
 >> vignette with no executable code in it.
 >>
 >
 > I understand that perfectly, but for instance my package declared 
already

 > has over 800 tests and 100% code coverage. More unit testing in the
 > vignettes really strikes as unnecessary.
 >
 > One other reason to use a static vignette, in my case, is that package
 > Sweave is not available for my version of R (on MacOS, M2 version)
As far as I know, there is no package called Sweave, there's just the 
Sweave() function in the utils package.>

 >
 >
 >> Still, you can ue the R.rsp package to provide static vignettes in
 >> both PDF and HTML formats:
 >>
 >> 
https://cran.r-project.org/package=R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf

 >>
 >> This will add 6 packages to your total Suggests budget:
 >>
 >> setdiff(
 >>   unlist(package_dependencies('R.rsp', recursive=TRUE)),
 >>   unlist(standard_package_names())
 >> )
 >> # [1] "R.methodsS3" "R.oo"    "R.utils" "R.cache" "digest"
 >
 >
 > Yes indeed, I know about R.rsp.
 > To me at least, zero dependency means that users install that package 
and

 > that package alone, the reason for which I am now looking for static
 > (preferably html) vignettes.
 >
 > I guess another question is why should the "Suggests" packages need 
to be

 > installed by end users. I understand CRAN checks need to make sure the
 > Vignettes can be processed and the code inside runs fine (just like the
 > examples in the Rd files) but it is very unlikely that end-users will 
want

 > to compile the vignettes themselves.
 >
 >  From my own experience of almost 20 years of using R, I never-ever 
build
 > the vignettes of a certain package because it is much simpler to read 
them

 > on CRAN. I wonder, then, why are end users forced to install
 > Vignette-building "Suggests" packages (with long dependency chains) when
 > they practically never do that.
 >
 > Life would be much simpler if the Suggests packages would not be
 > (automatically) installed, or if CRAN provided a way to include static
 > Vignettes to avoid the heavy dependencies of building them.
 >
Users aren't forced to install "Suggests" packages.  That's a choice 
they make.  The default for `install.packages()` is `dependencies = NA`, 
which says to install hard dependencies (Imports, Depends, LinkingTo).

Users have to choose a non-default setting to include Suggests.


Also note that the maintainer builds the vignette whe calling
R CMD build
CRAN checks whether the vignette can be build.
If a user installs a package, the already produced vignette (on the 
maintainers machine by R CMD build) is instaled. There is no need for 
the user to install any extra package for being able to look at the 
vignettes.


Best,
Uwe Ligges






Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [Rd] static html vignette

2024-01-04 Thread Duncan Murdoch


On 04/01/2024 11:43 a.m., Adrian Dușa wrote:
> (Moved here following Ivan's suggestion)
>
> On Thu, Jan 4, 2024 at 12:55 PM Ivan Krylov  
wrote:

>
>> On Thu, 4 Jan 2024 11:57:15 +0200
>> Adrian Dușa  wrote:
>>
>>> I wonder if it would be possible to include an html static vignette.
>>
>> I would say that static vignettes are against the spirit of vignettes:
>> the idea is to provide another layer of unit testing to the package by
>> providing a deeper executable example than is possible with just Rd
>> examples. I think that Bioconductor will even refuse a package with a
>> vignette with no executable code in it.
>>
>
> I understand that perfectly, but for instance my package declared already
> has over 800 tests and 100% code coverage. More unit testing in the
> vignettes really strikes as unnecessary.
>
> One other reason to use a static vignette, in my case, is that package
> Sweave is not available for my version of R (on MacOS, M2 version)
As far as I know, there is no package called Sweave, there's just the 
Sweave() function in the utils package.>

>
>
>> Still, you can ue the R.rsp package to provide static vignettes in
>> both PDF and HTML formats:
>>
>> 
https://cran.r-project.org/package=R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf

>>
>> This will add 6 packages to your total Suggests budget:
>>
>> setdiff(
>>   unlist(package_dependencies('R.rsp', recursive=TRUE)),
>>   unlist(standard_package_names())
>> )
>> # [1] "R.methodsS3" "R.oo""R.utils" "R.cache" "digest"
>
>
> Yes indeed, I know about R.rsp.
> To me at least, zero dependency means that users install that package and
> that package alone, the reason for which I am now looking for static
> (preferably html) vignettes.
>
> I guess another question is why should the "Suggests" packages need to be
> installed by end users. I understand CRAN checks need to make sure the
> Vignettes can be processed and the code inside runs fine (just like the
> examples in the Rd files) but it is very unlikely that end-users will 
want

> to compile the vignettes themselves.
>
>  From my own experience of almost 20 years of using R, I never-ever build
> the vignettes of a certain package because it is much simpler to read 
them

> on CRAN. I wonder, then, why are end users forced to install
> Vignette-building "Suggests" packages (with long dependency chains) when
> they practically never do that.
>
> Life would be much simpler if the Suggests packages would not be
> (automatically) installed, or if CRAN provided a way to include static
> Vignettes to avoid the heavy dependencies of building them.
>
Users aren't forced to install "Suggests" packages.  That's a choice 
they make.  The default for `install.packages()` is `dependencies = NA`, 
which says to install hard dependencies (Imports, Depends, LinkingTo).

Users have to choose a non-default setting to include Suggests.

Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [Rd] static html vignette

2024-01-04 Thread Adrian Dușa

(Moved here following Ivan's suggestion)

On Thu, Jan 4, 2024 at 12:55 PM Ivan Krylov  wrote:

> On Thu, 4 Jan 2024 11:57:15 +0200
> Adrian Dușa  wrote:
>
> > I wonder if it would be possible to include an html static vignette.
>
> I would say that static vignettes are against the spirit of vignettes:
> the idea is to provide another layer of unit testing to the package by
> providing a deeper executable example than is possible with just Rd
> examples. I think that Bioconductor will even refuse a package with a
> vignette with no executable code in it.
>

I understand that perfectly, but for instance my package declared already
has over 800 tests and 100% code coverage. More unit testing in the
vignettes really strikes as unnecessary.

One other reason to use a static vignette, in my case, is that package
Sweave is not available for my version of R (on MacOS, M2 version)

> Still, you can use the R.rsp package to provide static vignettes in
> both PDF and HTML formats:
>
> https://cran.r-project.org/package=R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf
>
> This will add 6 packages to your total Suggests budget:
>
> setdiff(
>  unlist(package_dependencies('R.rsp', recursive=TRUE)),
>  unlist(standard_package_names())
> )
> # [1] "R.methodsS3" "R.oo""R.utils" "R.cache" "digest"

Yes indeed, I know about R.rsp.
To me at least, zero dependency means that users install that package and
that package alone, the reason for which I am now looking for static
(preferably html) vignettes.

I guess another question is why should the "Suggests" packages need to be
installed by end users. I understand CRAN checks need to make sure the
Vignettes can be processed and the code inside runs fine (just like the
examples in the Rd files) but it is very unlikely that end-users will want
to compile the vignettes themselves.

>From my own experience of almost 20 years of using R, I never-ever build
the vignettes of a certain package because it is much simpler to read them
on CRAN. I wonder, then, why are end users forced to install
Vignette-building "Suggests" packages (with long dependency chains) when
they practically never do that.

Life would be much simpler if the Suggests packages would not be
(automatically) installed, or if CRAN provided a way to include static
Vignettes to avoid the heavy dependencies of building them.

Best regards,
Adrian

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Assigning an object to the global environment (shiny package)

Re: [R-pkg-devel] [Rd] static html vignette

Re: [R-pkg-devel] Assigning an object to the global environment (shiny package)

Re: [R-pkg-devel] [Rd] static html vignette

Re: [R-pkg-devel] Assigning an object to the global environment (shiny package)

Re: [R-pkg-devel] Assigning an object to the global environment (shiny package)

[R-pkg-devel] Assigning an object to the global environment (shiny package)

Re: [R-pkg-devel] [Rd] static html vignette

Re: [R-pkg-devel] [Rd] static html vignette

Re: [R-pkg-devel] [Rd] static html vignette

10 matches

Site Navigation

Mail list logo

Footer information