Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file
Dear all,
Thank you for your proposals and discussions. Accordingly, because it seems
there is no relevant alternative, I decided to propose an update of the «
survivalmodels » instead of the initial maintener for repositioning it in the
main CRAN repository and avoid the archiving of my package.
Thanks again.
Yohann
> Le 5 mars 2024 à 22:25, Dirk Eddelbuettel a écrit :
>
>
> 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
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
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
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
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
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
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/
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
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
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
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
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
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
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
