Re: [R-pkg-devel] [External] RcmdrPlugin.HH_1.1-48.tar.gz

[Richard M. Heiberger]

Thank you Duncan, Jeff, Ivan.

I did all that Duncan and Jeff suggested, plus a bit more that appeared to be 
necessary.
All of what I did is documented in the RcmdrPlugin.HH/NEWS file.

Ivan's comments were received after I sent 1.1-50 to CRAN and it was accepted.

I suggest that my notes in the NEWS file, perhaps augmented with Ivan's 
comments,
might be added to utils/man/globalVariables.Rd and to the
"
section ‘Package
structure’ in the ‘Writing R Extensions’ manual.
"


> On Mar 6, 2024, at 01:38, Ivan Krylov  wrote:
>
> В Tue, 5 Mar 2024 22:41:32 +
> "Richard M. Heiberger"  пишет:
>
>> Undocumented code objects:
>>   '.__global__'
>> All user-level objects in a package should have documentation
>> entries. See chapter 'Writing R documentation files' in the 'Writing R
>> Extensions' manual.
>
> This object is not here for the user of the package. If you don't
> export it, there will be no WARNING about it being undocumented. This
> variable is exported because of exportPattern(".") in the file
> NAMESPACE. The lone dot is a regular expression that matches any name
> of an R object.
>
> If you don't want to manually list your exports in the NAMESPACE file
> (which can get tedious) or generate it (which takes additional
> dependencies and build steps), you can use exportPattern('^[^\\.]') to
> export everything except objects with a name starting with a period:
> https://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exports
>
> --
> Best regards,
> Ivan

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

Re: [R-pkg-devel] RcmdrPlugin.HH_1.1-48.tar.gz

[Ivan Krylov via R-package-devel]

В Tue, 5 Mar 2024 22:41:32 +
"Richard M. Heiberger"  пишет:

>  Undocumented code objects:
>'.__global__'
>  All user-level objects in a package should have documentation
> entries. See chapter 'Writing R documentation files' in the 'Writing R
>  Extensions' manual.

This object is not here for the user of the package. If you don't
export it, there will be no WARNING about it being undocumented. This
variable is exported because of exportPattern(".") in the file
NAMESPACE. The lone dot is a regular expression that matches any name
of an R object.

If you don't want to manually list your exports in the NAMESPACE file
(which can get tedious) or generate it (which takes additional
dependencies and build steps), you can use exportPattern('^[^\\.]') to
export everything except objects with a name starting with a period:
https://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exports

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] [External] RcmdrPlugin.HH_1.1-48.tar.gz

[Jeff Newmiller via R-package-devel]

Remove leading periods from all file names in the tar.gz. Use .Rbuildignore to 
handle such files in your dev directory if you need them. Maybe also look at 
[1].

 [1] 
https://stackoverflow.com/questions/40950799/r-cmd-check-error-how-to-get-rid-of-hidden-files-and-directory-in-devel-r-pack

On March 5, 2024 5:34:36 PM PST, "Richard M. Heiberger"  wrote:
>Almost.
>
>I used 
>prompt(".__global__")
>to create file
>man/.__global__.Rd
>
>This file does not appear in the tar.gz file, but without a note of rejection.
>When I checked my disk directory directly
>R CMD check RcmdrPlugin.HH
>the file was rejected with
>
>Found the following hidden files and directories:
>  .DS_Store
>  R/.DS_Store
>  man/.__global__.Rd
>These were most likely included in error. See section ‘Package
>structure’ in the ‘Writing R Extensions’ manual.
>
>I looked there
>Section 1.1 says that the acceptable characters are
>A-Za-z0-9._!#$%&+,;=@^(){}'[]
>and "." and _ are explicitly included.
>
>What should I try next?
>
>
>> On Mar 5, 2024, at 18:21, Duncan Murdoch  wrote:
>> 
>> On 05/03/2024 5:41 p.m., Richard M. Heiberger wrote:
>>> My package is being rejected by auto-check
>>> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
>>> Check: for missing documentation entries, Result: WARNING
>>>  Undocumented code objects:
>>>'.__global__'
>>>  All user-level objects in a package should have documentation entries.
>>>  See chapter 'Writing R documentation files' in the 'Writing R
>>>  Extensions' manual.
>>> The problem is that the string'.__global__'  is not in the package.
>>> I can't find it and John Fox, the maintainer of Rcmdr, can'f find it.
>>> Can someone help me understand why a non-existent string is being detected?
>> 
>> That's the variable modified by the `globalVariables()` function.  So it may 
>> well exist in your package.  I'd guess the problem is that your package 
>> exports functions by giving a pattern for the names instead of listing each 
>> one separately, and it matches that variable.
>> 
>> Duncan Murdoch
>> 
>> 
>> 
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] [External] RcmdrPlugin.HH_1.1-48.tar.gz

[Richard M. Heiberger]

Almost.

I used 
prompt(".__global__")
to create file
man/.__global__.Rd

This file does not appear in the tar.gz file, but without a note of rejection.
When I checked my disk directory directly
R CMD check RcmdrPlugin.HH
the file was rejected with

Found the following hidden files and directories:
  .DS_Store
  R/.DS_Store
  man/.__global__.Rd
These were most likely included in error. See section ‘Package
structure’ in the ‘Writing R Extensions’ manual.

I looked there
Section 1.1 says that the acceptable characters are
A-Za-z0-9._!#$%&+,;=@^(){}'[]
and "." and _ are explicitly included.

What should I try next?


> On Mar 5, 2024, at 18:21, Duncan Murdoch  wrote:
> 
> On 05/03/2024 5:41 p.m., Richard M. Heiberger wrote:
>> My package is being rejected by auto-check
>> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
>> Check: for missing documentation entries, Result: WARNING
>>  Undocumented code objects:
>>'.__global__'
>>  All user-level objects in a package should have documentation entries.
>>  See chapter 'Writing R documentation files' in the 'Writing R
>>  Extensions' manual.
>> The problem is that the string'.__global__'  is not in the package.
>> I can't find it and John Fox, the maintainer of Rcmdr, can'f find it.
>> Can someone help me understand why a non-existent string is being detected?
> 
> That's the variable modified by the `globalVariables()` function.  So it may 
> well exist in your package.  I'd guess the problem is that your package 
> exports functions by giving a pattern for the names instead of listing each 
> one separately, and it matches that variable.
> 
> Duncan Murdoch
> 
> 
> 

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

Re: [R-pkg-devel] RFC: C backtraces for R CMD check via just-in-time debugging

[Vladimir Dergachev]

I use libunwind in my programs, works quite well, and simple to use.

Happy to share the code if there is interest..

best

Vladimir Dergachev

On Mon, 4 Mar 2024, Ivan Krylov via R-package-devel wrote:


On Sun, 3 Mar 2024 19:19:43 -0800
Kevin Ushey  wrote:


Would libSegFault be useful here?


Glad to know it has been moved to
 and not
just removed altogether after the upstream commit
.

libSegFault is safer than, say, libsegfault [*] because it both
supports SA_ONSTACK (for when a SIGSEGV is caused by stack overflow)
and avoids functions like snprintf() (which depend on the locale code,
which may have been the source of the crash). The only correctness
problem that may still be unaddressed is potential memory allocations
in backtrace() when it loads libgcc on first use. That should be easy
to fix by calling backtrace() once in segfault_init(). Unfortunately,
libSegFault is limited to glibc systems, so a different solution will
be needed on Windows, macOS and Linux systems with the musl libc.

Google-owned "backward" [**] tries to do most of this right, but (1) is
designed to be compiled together with C++ programs, not injected into
unrelated processes and (2) will exit the process if it survives
raise(signum), which will interfere with both rJava (judging by the
number of Java-related SIGSEGVs I saw while running R CMD check) and R's
own stack overflow survival attempts.

--
Best regards,
Ivan

[*] https://github.com/stass/libsegfault
(Which doesn't compile out of the box on GNU/Linux due to missing
pthread_np.h, although that should be easy to patch.)

[**] https://github.com/bombela/backward-cpp

__
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] RcmdrPlugin.HH_1.1-48.tar.gz

[Duncan Murdoch]

On 05/03/2024 5:41 p.m., Richard M. Heiberger wrote:

My package is being rejected by auto-check

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
Check: for missing documentation entries, Result: WARNING
  Undocumented code objects:
'.__global__'
  All user-level objects in a package should have documentation entries.
  See chapter 'Writing R documentation files' in the 'Writing R
  Extensions' manual.

The problem is that the string'.__global__'  is not in the package.
I can't find it and John Fox, the maintainer of Rcmdr, can'f find it.

Can someone help me understand why a non-existent string is being detected?



That's the variable modified by the `globalVariables()` function.  So it 
may well exist in your package.  I'd guess the problem is that your 
package exports functions by giving a pattern for the names instead of 
listing each one separately, and it matches that variable.


Duncan Murdoch

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

[R-pkg-devel] RcmdrPlugin.HH_1.1-48.tar.gz

[Richard M. Heiberger]

My package is being rejected by auto-check

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
Check: for missing documentation entries, Result: WARNING
 Undocumented code objects:
   '.__global__'
 All user-level objects in a package should have documentation entries.
 See chapter 'Writing R documentation files' in the 'Writing R
 Extensions' manual.

The problem is that the string'.__global__'  is not in the package.
I can't find it and John Fox, the maintainer of Rcmdr, can'f find it.

Can someone help me understand why a non-existent string is being detected?

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

Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file

[Dirk Eddelbuettel]

On 5 March 2024 at 15:12, Duncan Murdoch wrote:
| On 05/03/2024 2:26 p.m., Dirk Eddelbuettel wrote:
| > The default behaviour is to build after every commit to the main branch.  
But
| > there are options. On the repo I mentioned we use
| > 
| >  "branch": "*release",
| 
| Where do you put that?  I don't see r2u on R-universe, so I guess you're 
| talking about a different repo; which one?

In the (optional) control repo that can drive your 'r-universe', and the file
has to be named 'packages.json'. For you the repo would

https://github.com/dmurdoch/dmurdoch.r-universe.dev

(and the naming rule was tightened by Jeroen recently -- we used to call
these just 'universe', now it has to match your runiverse)

The file packages.json would then have a block

  {
"package": "rgl",
"maintainer": "Duncan Murdoch "
"url": "https://github.com/dmurdoch/rgl;,
"available": true,
"branch": "*release"
  }

The reference I mentioned is our package 'tiledbsoma' (joint work of TileDB
and CZI, in https://github.com/single-cell-data/TileDB-SOMA) and described here:

https://github.com/TileDB-Inc/tiledb-inc.r-universe.dev/blob/master/packages.json
 

(and you can ignore the '"subdir": "apis/r"' which is a facet local to that 
repo).

Note that 'my' packages.json in my eddelbuettel.r-universe.dev ie

https://github.com/eddelbuettel/eddelbuettel.r-universe.dev/blob/master/packages.json

also describe but without the '"branch": "*release"' and that builds with every 
merge to
the main branch by my choice; that build is mine and 'inofficial' giving us two.

| > It is under your control. You could document how to install via `remotes`
| > from that branch.  As so often, it's about trading one thing off for 
another.
| 
| I do that, but my documentation falls off the bottom of the screen, and 
| the automatic docs generated by R-universe are at the top.

I always get lost in the r-universe docs too. Some, as Jeroen kindly reminded
me the other day, are here:  https://github.com/r-universe-org

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file

[Duncan Murdoch]

On 05/03/2024 2:26 p.m., Dirk Eddelbuettel wrote:


On 5 March 2024 at 13:28, Duncan Murdoch wrote:
| What I'm seeing is that the tags are ignored, and it is distributing the
| HEAD of the main branch.  I don't think most users should be using that
| version:  in my packages it won't have had full reverse dependency
| checks, I only do that before CRAN releases.  And occasionally it hasn't
| even passed R CMD check, though that's not my normal workflow.  On the
| other hand, I like that it's available and easy to install, it just
| shouldn't be the default install.

The default behaviour is to build after every commit to the main branch.  But
there are options. On the repo I mentioned we use

 "branch": "*release",


Where do you put that?  I don't see r2u on R-universe, so I guess you're 
talking about a different repo; which one?




and now builds occur on tagged releases only. The above is AFAIUI a meta
declaration understood by `remotes`, it was an option suggested by a
colleague.  Naming actual branches also works.
  
| I suppose I could do all development on a "devel" branch, and only merge

| it into the main branch after I wanted to make a release, but then the
| R-universe instructions would be no good for getting the devel code.

It is under your control. You could document how to install via `remotes`
from that branch.  As so often, it's about trading one thing off for another.


I do that, but my documentation falls off the bottom of the screen, and 
the automatic docs generated by R-universe are at the top.


Duncan



| I don't know anything about dpkg, but having some options available to
| package authors would be a good thing.

Yes but you know {install,available}.packages and have some understanding of
how R identifies and installs packages. I merely illustrated a different use
pattern of giving "weights" to repos. If "we all" want different behaviour,
someone has to site down and write it. Discussing some possible specs and
desired behavior may help.

Dirk



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

Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file

[Dirk Eddelbuettel]

On 5 March 2024 at 13:28, Duncan Murdoch wrote:
| What I'm seeing is that the tags are ignored, and it is distributing the 
| HEAD of the main branch.  I don't think most users should be using that 
| version:  in my packages it won't have had full reverse dependency 
| checks, I only do that before CRAN releases.  And occasionally it hasn't 
| even passed R CMD check, though that's not my normal workflow.  On the 
| other hand, I like that it's available and easy to install, it just 
| shouldn't be the default install.

The default behaviour is to build after every commit to the main branch.  But
there are options. On the repo I mentioned we use

"branch": "*release",

and now builds occur on tagged releases only. The above is AFAIUI a meta
declaration understood by `remotes`, it was an option suggested by a
colleague.  Naming actual branches also works.
 
| I suppose I could do all development on a "devel" branch, and only merge 
| it into the main branch after I wanted to make a release, but then the 
| R-universe instructions would be no good for getting the devel code.

It is under your control. You could document how to install via `remotes`
from that branch.  As so often, it's about trading one thing off for another.

| I don't know anything about dpkg, but having some options available to 
| package authors would be a good thing.

Yes but you know {install,available}.packages and have some understanding of
how R identifies and installs packages. I merely illustrated a different use
pattern of giving "weights" to repos. If "we all" want different behaviour,
someone has to site down and write it. Discussing some possible specs and
desired behavior may help. 

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file

[Duncan Murdoch]

On 05/03/2024 1:04 p.m., Dirk Eddelbuettel wrote:


On 5 March 2024 at 11:56, Duncan Murdoch wrote:
| I have mixed feelings about r-universe.  On the one hand, it is really
| nicely put together, and it offers the service described above.  On the
| other, it's probably a bad idea to follow its advice and use
| install.packages() with `repos` as shown:  that will install development
| versions of packages, not releases.

Yup. It's a point I raised right at the start as I really do believe in
curated releases but clearly a lot of people prefer the simplicity of
'tagging a release' at GitHub and then getting a build.


What I'm seeing is that the tags are ignored, and it is distributing the 
HEAD of the main branch.  I don't think most users should be using that 
version:  in my packages it won't have had full reverse dependency 
checks, I only do that before CRAN releases.  And occasionally it hasn't 
even passed R CMD check, though that's not my normal workflow.  On the 
other hand, I like that it's available and easy to install, it just 
shouldn't be the default install.


I suppose I could do all development on a "devel" branch, and only merge 
it into the main branch after I wanted to make a release, but then the 
R-universe instructions would be no good for getting the devel code.




r-universe is indeed good at what it does and reliable. There are limited
choices in 'driving' what you can do with it.  We rely quite heavily on it in
a large project for work.  As each 'repo' can appear only once in a universe,
we resorted to having the 'offical' build follow GitHub 'releases', as well
as (optional, additional) builds against a the main branch from another
universe.  This example is for a non-CRAN package.





With CRAN packages, r-universe can be useful too. For some of my packages, I
now show multiple 'badges' at the README: for the released CRAN version as
well as for the current 'rc' in the main branch sporting a differentiating
final digit.  RcppArmadillo had a pre-releases available to test that way for
a few weeks til the new release this week.  So in effect, this gives you what
`drat` allows yet also automagically adds builds. It's quite useful when you
are careful about it.
  
| Do you know if it's possible for a package to suggest the CRAN version

| first, with an option like the above only offered as a pre-release option?

In the language of Debian and its dpkg and tools, one solution to that would
be 'repository pinning' to declare a 'value' on a repository.  There, the
default is 500, and e.g. for r2u I set this to 700 as you usually want its
versions.

We do not have this for R, but it could be added (eventually) as a new value
in PACKAGES, or as a new supplementary attribute.


I don't know anything about dpkg, but having some options available to 
package authors would be a good thing.


Duncan Murdoch

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

Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file

[Dirk Eddelbuettel]

On 5 March 2024 at 11:56, Duncan Murdoch wrote:
| I have mixed feelings about r-universe.  On the one hand, it is really 
| nicely put together, and it offers the service described above.  On the 
| other, it's probably a bad idea to follow its advice and use 
| install.packages() with `repos` as shown:  that will install development 
| versions of packages, not releases.

Yup. It's a point I raised right at the start as I really do believe in
curated releases but clearly a lot of people prefer the simplicity of
'tagging a release' at GitHub and then getting a build.

r-universe is indeed good at what it does and reliable. There are limited
choices in 'driving' what you can do with it.  We rely quite heavily on it in
a large project for work.  As each 'repo' can appear only once in a universe,
we resorted to having the 'offical' build follow GitHub 'releases', as well
as (optional, additional) builds against a the main branch from another
universe.  This example is for a non-CRAN package.

With CRAN packages, r-universe can be useful too. For some of my packages, I
now show multiple 'badges' at the README: for the released CRAN version as
well as for the current 'rc' in the main branch sporting a differentiating
final digit.  RcppArmadillo had a pre-releases available to test that way for
a few weeks til the new release this week.  So in effect, this gives you what
`drat` allows yet also automagically adds builds. It's quite useful when you
are careful about it.
 
| Do you know if it's possible for a package to suggest the CRAN version 
| first, with an option like the above only offered as a pre-release option?

In the language of Debian and its dpkg and tools, one solution to that would
be 'repository pinning' to declare a 'value' on a repository.  There, the
default is 500, and e.g. for r2u I set this to 700 as you usually want its
versions.

We do not have this for R, but it could be added (eventually) as a new value
in PACKAGES, or as a new supplementary attribute.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file

[Duncan Murdoch]

On 05/03/2024 12:08 p.m., Josiah Parry wrote:
My understanding is that the order of CRAN repos available in 
`options("repos")` are tried sequentially. So if cran.r-rproject.org 
 is first, that will be tried. If the 
package is not available there, the next repository will be tried.


I think that's correct, but as in the example below, the R-universe 
repos is usually listed first.


I do appreciate the ease of release to R-universe quite a bit 
particularly because you don’t need to vendor rust deps.


Is it really a release if the author doesn't know it happened?  I found 
out about "my" site dmurdoch.r-universe.dev today, but it seems to have 
existed for quite a while.


Duncan Murdoch



On Tue, Mar 5, 2024 at 11:56 AM Duncan Murdoch > wrote:


On 05/03/2024 8:02 a.m., Dirk Eddelbuettel wrote:
 >
 > On 5 March 2024 at 06:25, Duncan Murdoch wrote:
 > | You could make a compatible version of `survivalmodels`
available on a
 > | non-CRAN website, and refer to that website in the
 > | Additional_repositories field of DESCRIPTION.
 >
 > Every r-universe sub-site fits that requirement. For this package
Google's
 > first hit was https://raphaels1.r-universe.dev/survivalmodels
 and it carries
 > the same line on install.packages() that Jeroen adds to every page:
 >
 >   install.packages('survivalmodels', repos =
c('https://raphaels1.r-universe.dev ',
 >   
'https://cloud.r-project.org '))


I have mixed feelings about r-universe.  On the one hand, it is really
nicely put together, and it offers the service described above.  On the
other, it's probably a bad idea to follow its advice and use
install.packages() with `repos` as shown:  that will install
development
versions of packages, not releases.

Do you know if it's possible for a package to suggest the CRAN version
first, with an option like the above only offered as a pre-release
option?

Duncan Murdoch

 >
 > So doing all three of
 > - adding a line 'Additional_repositories:
https://raphaels1.r-universe.dev '
 > - adding a 'Suggests: survivalmodels;
 > - ensuring conditional use only as Suggests != Depends
 > should do.
 >
 > | It would be best if you fixed whatever issue caused
survivalmodels to be
 > | archived when you do this.
 > |
 > | Looking here:
 > |

https://cran-archive.r-project.org/web/checks/2024/2024-03-02_check_results_survivalmodels.html
 

 > | that appears very easy to do.  The source is here:
 > | https://github.com/RaphaelS1/survivalmodels/
 .
 >
 > The other may even take a PR fixing this going forward.
 >
 > Dirk
 >

__
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] Suggesting an archived package in the DESCRIPTION file

[Josiah Parry]

My understanding is that the order of CRAN repos available in
`options("repos")` are tried sequentially. So if cran.r-rproject.org is
first, that will be tried. If the package is not available there, the next
repository will be tried.

I do appreciate the ease of release to R-universe quite a bit particularly
because you don’t need to vendor rust deps.

On Tue, Mar 5, 2024 at 11:56 AM Duncan Murdoch 
wrote:

> On 05/03/2024 8:02 a.m., Dirk Eddelbuettel wrote:
> >
> > On 5 March 2024 at 06:25, Duncan Murdoch wrote:
> > | You could make a compatible version of `survivalmodels` available on a
> > | non-CRAN website, and refer to that website in the
> > | Additional_repositories field of DESCRIPTION.
> >
> > Every r-universe sub-site fits that requirement. For this package
> Google's
> > first hit was https://raphaels1.r-universe.dev/survivalmodels and it
> carries
> > the same line on install.packages() that Jeroen adds to every page:
> >
> >   install.packages('survivalmodels', repos = c('
> https://raphaels1.r-universe.dev',
> >'
> https://cloud.r-project.org'))
>
> I have mixed feelings about r-universe.  On the one hand, it is really
> nicely put together, and it offers the service described above.  On the
> other, it's probably a bad idea to follow its advice and use
> install.packages() with `repos` as shown:  that will install development
> versions of packages, not releases.
>
> Do you know if it's possible for a package to suggest the CRAN version
> first, with an option like the above only offered as a pre-release option?
>
> Duncan Murdoch
>
> >
> > So doing all three of
> > - adding a line 'Additional_repositories:
> https://raphaels1.r-universe.dev'
> > - adding a 'Suggests: survivalmodels;
> > - ensuring conditional use only as Suggests != Depends
> > should do.
> >
> > | It would be best if you fixed whatever issue caused survivalmodels to
> be
> > | archived when you do this.
> > |
> > | Looking here:
> > |
> https://cran-archive.r-project.org/web/checks/2024/2024-03-02_check_results_survivalmodels.html
> > | that appears very easy to do.  The source is here:
> > | https://github.com/RaphaelS1/survivalmodels/ .
> >
> > The other may even take a PR fixing this going forward.
> >
> > Dirk
> >
>
> __
> 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] Suggesting an archived package in the DESCRIPTION file

[Duncan Murdoch]

On 05/03/2024 8:02 a.m., Dirk Eddelbuettel wrote:


On 5 March 2024 at 06:25, Duncan Murdoch wrote:
| You could make a compatible version of `survivalmodels` available on a
| non-CRAN website, and refer to that website in the
| Additional_repositories field of DESCRIPTION.

Every r-universe sub-site fits that requirement. For this package Google's
first hit was https://raphaels1.r-universe.dev/survivalmodels and it carries
the same line on install.packages() that Jeroen adds to every page:

  install.packages('survivalmodels', repos = 
c('https://raphaels1.r-universe.dev',
   'https://cloud.r-project.org'))


I have mixed feelings about r-universe.  On the one hand, it is really 
nicely put together, and it offers the service described above.  On the 
other, it's probably a bad idea to follow its advice and use 
install.packages() with `repos` as shown:  that will install development 
versions of packages, not releases.


Do you know if it's possible for a package to suggest the CRAN version 
first, with an option like the above only offered as a pre-release option?


Duncan Murdoch



So doing all three of
- adding a line 'Additional_repositories: https://raphaels1.r-universe.dev'
- adding a 'Suggests: survivalmodels;
- ensuring conditional use only as Suggests != Depends
should do.

| It would be best if you fixed whatever issue caused survivalmodels to be
| archived when you do this.
|
| Looking here:
| 
https://cran-archive.r-project.org/web/checks/2024/2024-03-02_check_results_survivalmodels.html
| that appears very easy to do.  The source is here:
| https://github.com/RaphaelS1/survivalmodels/ .

The other may even take a PR fixing this going forward.

Dirk



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

Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file

[Dirk Eddelbuettel]

On 5 March 2024 at 06:25, Duncan Murdoch wrote:
| You could make a compatible version of `survivalmodels` available on a 
| non-CRAN website, and refer to that website in the 
| Additional_repositories field of DESCRIPTION.

Every r-universe sub-site fits that requirement. For this package Google's
first hit was https://raphaels1.r-universe.dev/survivalmodels and it carries
the same line on install.packages() that Jeroen adds to every page:

 install.packages('survivalmodels', repos = 
c('https://raphaels1.r-universe.dev',
  'https://cloud.r-project.org'))

So doing all three of 
- adding a line 'Additional_repositories: https://raphaels1.r-universe.dev'
- adding a 'Suggests: survivalmodels;
- ensuring conditional use only as Suggests != Depends
should do.

| It would be best if you fixed whatever issue caused survivalmodels to be 
| archived when you do this.
| 
| Looking here: 
| 
https://cran-archive.r-project.org/web/checks/2024/2024-03-02_check_results_survivalmodels.html
| that appears very easy to do.  The source is here: 
| https://github.com/RaphaelS1/survivalmodels/ .

The other may even take a PR fixing this going forward.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file

[Duncan Murdoch]

On 05/03/2024 5:58 a.m., Yohann Foucher wrote:

Dear R-Members,


I just have submitted an update of the ‘survivalSL' package because the last version 
depends on the ‘survivalmodels’ package, which has been recently archived.  In the 
DESCRIPTION file of the new version 0.93 of the ‘survivalSL' package, I've moved 
‘survivalmodels' from "Depends" to the ‘Suggests'. I thought this would solve 
the problem. Indeed, the 'survivalSL’ package can function without the ‘survivalmodels’ 
package if the user does not include the related learner (survival neural network) in the 
learning ensemble. Nevertheless, the new version 0.93 was archived again.

I’m working on the estimation of a survival neural network without the 
‘survivalmodels’ package but this developments will take a long time. During 
this period, do you have any idea to avoid the archiving of my package?


You could make a compatible version of `survivalmodels` available on a 
non-CRAN website, and refer to that website in the 
Additional_repositories field of DESCRIPTION.


It would be best if you fixed whatever issue caused survivalmodels to be 
archived when you do this.


Looking here: 
https://cran-archive.r-project.org/web/checks/2024/2024-03-02_check_results_survivalmodels.html
that appears very easy to do.  The source is here: 
https://github.com/RaphaelS1/survivalmodels/ .


Alternatively, you could just drop the functions that depend on 
survivalmodels completely, and drop it as a Suggested package.


Duncan Murdoch

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

Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file

[Uwe Ligges]

Suggested packages should be used conditionally. If available, use it, 
otherwise the code should fail gracefully.


Best,
Uwe Ligges


On 05.03.2024 11:58, Yohann Foucher wrote:

Dear R-Members,


I just have submitted an update of the ‘survivalSL' package because the last version 
depends on the ‘survivalmodels’ package, which has been recently archived.  In the 
DESCRIPTION file of the new version 0.93 of the ‘survivalSL' package, I've moved 
‘survivalmodels' from "Depends" to the ‘Suggests'. I thought this would solve 
the problem. Indeed, the 'survivalSL’ package can function without the ‘survivalmodels’ 
package if the user does not include the related learner (survival neural network) in the 
learning ensemble. Nevertheless, the new version 0.93 was archived again.

I’m working on the estimation of a survival neural network without the 
‘survivalmodels’ package but this developments will take a long time. During 
this period, do you have any idea to avoid the archiving of my package?

Thank you for your help.


Yohann

__
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

[R-pkg-devel] Suggesting an archived package in the DESCRIPTION file

[Yohann Foucher]

Dear R-Members,


I just have submitted an update of the ‘survivalSL' package because the last 
version depends on the ‘survivalmodels’ package, which has been recently 
archived.  In the DESCRIPTION file of the new version 0.93 of the ‘survivalSL' 
package, I've moved ‘survivalmodels' from "Depends" to the ‘Suggests'. I 
thought this would solve the problem. Indeed, the 'survivalSL’ package can 
function without the ‘survivalmodels’ package if the user does not include the 
related learner (survival neural network) in the learning ensemble. 
Nevertheless, the new version 0.93 was archived again. 

I’m working on the estimation of a survival neural network without the 
‘survivalmodels’ package but this developments will take a long time. During 
this period, do you have any idea to avoid the archiving of my package?

Thank you for your help.


Yohann

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