[R-pkg-devel] LaTeX issues on r-devel-windows-x86_64-gcc10-UCRT?

[Stephan Struckmann]

Dear all,

lately, an error and two warnings occurred for our package dataquieR on the 
platform r-devel-windows-x86_64-gcc10-UCRT 
(https://cran.r-project.org/web/checks/check_results_dataquieR.html). 

Unfortunately, error messages/warnings are likely related to the test system’s 
configuration/setup:

  - Missing file /msys64/home/tomas/ucrt3/svn/ucrt3/r_packages/patches_idx.rds

  - "LaTeX errors“ without further specification, rather unspecific.

I have now re-built this environment as close as I could according to the 
platform description and given my infrastructure. In this setup, I had a 
missing font in the end in my test installation. 

After I had applied this: https://tex.stackexchange.com/a/129523 (setup 
configuration for the font ts1-zi4r), the pdf could be created. The warning 
about missing patches_idx.rds, I could not reproduce, but this may be less 
relevant anyway.

The setup, I used (hopefully close to r-devel-windows-x86_64-gcc10-UCRT) was

  - Microsoft Windows 10 Enterprise LTSC, 10.0.17763 Build 17763
  - R 4.2.0 Pre Release UCRT3 downloaded today from r-project.org as the only R 
installation
  - Rtools 4.0.2.0.1 downloaded today from r-project.org as the only Rtools 
installation
  - For TeX, I installed MiKTeX 21.6 as the only TeX installation.
  - all binaries were put on the PATH environment variable

—— 

Now my question: Is this related to CRAN’s r-devel-windows-x86_64-gcc10-UCRT 
and can that be fixed there? Whom should I contact at CRAN?

Thank you in advance,

Stephan



--
Dr. Stephan Struckmann
stephan.struckm...@uni-greifswald.de
Biomathematiker/Informatiker/Apotheker
Tel. +49 (0) 3834 - 86 77 83

Institut für Community Medicine 
Walther-Rathenau-Str. 48 
17475 Greifswald

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

[R-pkg-devel] What is a "retired"package?

[Lenth, Russell V]

I received a request that I remove the 'plyr' package from the Imports for my 
package, because plyr is retired. Indeed, the README file for plyr states:

> plyr is retired: this means only changes necessary to keep it on CRAN 
will be made. 
> We recommend using dplyr (for data frames) or purrr (for lists) instead.

This says "retired" but it also suggests that plyr will continue to be 
maintained. And that is a good thing because plyr has over 700 direct 
reverse-dependents, and almost 2000 if we include indirect reverse 
dependencies. 

So it seems to me that it isn't a problem at all to have my package import 
plyr. I use its 'aaply' and 'alply' functions, which are like 'apply' but work 
for any dimensional array. There are no obvious replacements in purrr or dplyr, 
and if there were and I used them instead, it would increase my indirect 
dependencies to several packages that are not actually needed.

The user requesting that I drop plyr states that this is needed to satisfy 
regulatory needs, that it is problematic to qualify my package since it imports 
a retired package. 

So my question is: Is there a specific meaning in CRAN for "retired," or is 
that just loose language from the plyr developers? I did not find the term in 
"CRAN Repository Policy" or "Writing R Extensions." It appears that my user or 
their regulatory agency thinks it means that it could be deprecated in the near 
future. (If that is indeed what it means, there are 700+ packages in trouble!) 
Otherwise, perhaps the appropriate request may be to the plyr maintainers to 
modify how they describe its status, so as to avoid confusion.

Russ Lenth
University of Iowa

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

Re: [R-pkg-devel] What is a "retired"package?

[Lionel Henry]

Hello,

We renamed "retired" to "superseded" some time ago to avoid any
confusion. Superseded functions and packages continue to be maintained
on CRAN for the foreseeable future and it is safe to depend on them.
See the "superseded" definition in https://tidyverse.org/lifecycle/.

plyr probably still mentions "retired" because it is rarely updated
(only when a CRAN failure requires attention).

Best,
Lionel



On 9/21/21, Lenth, Russell V  wrote:
> I received a request that I remove the 'plyr' package from the Imports for
> my package, because plyr is retired. Indeed, the README file for plyr
> states:
>
> > plyr is retired: this means only changes necessary to keep it on CRAN
> will be made.
> > We recommend using dplyr (for data frames) or purrr (for lists)
> instead.
>
> This says "retired" but it also suggests that plyr will continue to be
> maintained. And that is a good thing because plyr has over 700 direct
> reverse-dependents, and almost 2000 if we include indirect reverse
> dependencies.
>
> So it seems to me that it isn't a problem at all to have my package import
> plyr. I use its 'aaply' and 'alply' functions, which are like 'apply' but
> work for any dimensional array. There are no obvious replacements in purrr
> or dplyr, and if there were and I used them instead, it would increase my
> indirect dependencies to several packages that are not actually needed.
>
> The user requesting that I drop plyr states that this is needed to satisfy
> regulatory needs, that it is problematic to qualify my package since it
> imports a retired package.
>
> So my question is: Is there a specific meaning in CRAN for "retired," or is
> that just loose language from the plyr developers? I did not find the term
> in "CRAN Repository Policy" or "Writing R Extensions." It appears that my
> user or their regulatory agency thinks it means that it could be deprecated
> in the near future. (If that is indeed what it means, there are 700+
> packages in trouble!) Otherwise, perhaps the appropriate request may be to
> the plyr maintainers to modify how they describe its status, so as to avoid
> confusion.
>
> Russ Lenth
> University of Iowa
>
> __
> 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] What is a "retired"package?

[Jeff Newmiller]

There is nothing official about that term. However, the meaning as intended by 
the package authors seems pretty clear to me, and if some organization decides 
not to allow software that is not being maintained to be relied upon then that 
is their decision. I don't think slapping a different label on "I am not fixing 
this hot mess" is going to change that organization's stance, and expecting the 
author to play that game is unreasonable.

Welcome to the downside of package interdependencies. I highly recommend that 
you migrate away from plyr, either by absorbing the key functions you need from 
it or by relying on different packages.

On September 21, 2021 8:15:28 AM PDT, "Lenth, Russell V" 
 wrote:
>I received a request that I remove the 'plyr' package from the Imports for my 
>package, because plyr is retired. Indeed, the README file for plyr states:
>
>> plyr is retired: this means only changes necessary to keep it on CRAN 
> will be made. 
>> We recommend using dplyr (for data frames) or purrr (for lists) instead.
>
>This says "retired" but it also suggests that plyr will continue to be 
>maintained. And that is a good thing because plyr has over 700 direct 
>reverse-dependents, and almost 2000 if we include indirect reverse 
>dependencies. 
>
>So it seems to me that it isn't a problem at all to have my package import 
>plyr. I use its 'aaply' and 'alply' functions, which are like 'apply' but work 
>for any dimensional array. There are no obvious replacements in purrr or 
>dplyr, and if there were and I used them instead, it would increase my 
>indirect dependencies to several packages that are not actually needed.
>
>The user requesting that I drop plyr states that this is needed to satisfy 
>regulatory needs, that it is problematic to qualify my package since it 
>imports a retired package. 
>
>So my question is: Is there a specific meaning in CRAN for "retired," or is 
>that just loose language from the plyr developers? I did not find the term in 
>"CRAN Repository Policy" or "Writing R Extensions." It appears that my user or 
>their regulatory agency thinks it means that it could be deprecated in the 
>near future. (If that is indeed what it means, there are 700+ packages in 
>trouble!) Otherwise, perhaps the appropriate request may be to the plyr 
>maintainers to modify how they describe its status, so as to avoid confusion.
>
>Russ Lenth
>University of Iowa
>
>__
>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] Re: What is a "retired"package?

[Lenth, Russell V]

From: Andrew Simmons akwsi...@gmail.com

> Doesn't apply already work on any dimensional arrays using argument MARGIN?

Egads, yes it does! I can't explain why I didn't know that...

Russ


[[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] [External] Re: What is a "retired"package?

[Lenth, Russell V]

... "I am not fixing this hot mess"??? To the contrary, the README contains a 
clearly expressed intention to maintain plyr to keep in on CRAN.

RL

-Original Message-
From: Jeff Newmiller  
Sent: Tuesday, September 21, 2021 10:36 AM
To: r-package-devel@r-project.org; Lenth, Russell V ; 
r-package-devel@r-project.org
Subject: [External] Re: [R-pkg-devel] What is a "retired"package?

There is nothing official about that term. However, the meaning as intended by 
the package authors seems pretty clear to me, and if some organization decides 
not to allow software that is not being maintained to be relied upon then that 
is their decision. I don't think slapping a different label on "I am not fixing 
this hot mess" is going to change that organization's stance, and expecting the 
author to play that game is unreasonable.

Welcome to the downside of package interdependencies. I highly recommend that 
you migrate away from plyr, either by absorbing the key functions you need from 
it or by relying on different packages.

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

Re: [R-pkg-devel] LaTeX issues on r-devel-windows-x86_64-gcc10-UCRT?

[Tomas Kalibera]

Dear Stephan,

On 9/21/21 3:31 PM, Stephan Struckmann wrote:
> Dear all,
>
> lately, an error and two warnings occurred for our package dataquieR on the 
> platform r-devel-windows-x86_64-gcc10-UCRT 
> (https://cran.r-project.org/web/checks/check_results_dataquieR.html).
>
> Unfortunately, error messages/warnings are likely related to the test 
> system’s configuration/setup:
>
>- Missing file 
> /msys64/home/tomas/ucrt3/svn/ucrt3/r_packages/patches_idx.rds

thanks for the report. This is due to a problem that prevented building 
the patch index (so yes, the test system), I've fixed it earlier today 
and new results should appear in about a day.

>- "LaTeX errors“ without further specification, rather unspecific.
>
> I have now re-built this environment as close as I could according to the 
> platform description and given my infrastructure. In this setup, I had a 
> missing font in the end in my test installation.
>
> After I had applied this: https://tex.stackexchange.com/a/129523 (setup 
> configuration for the font ts1-zi4r), the pdf could be created. The warning 
> about missing patches_idx.rds, I could not reproduce, but this may be less 
> relevant anyway.

Thanks, I will try this out when the current run finishes, if the LaTeX 
error still appears.

The machine uses the latest MiKTeX (21.8), which crashes e.g. when 
running "texify --version segfaults". I've reported this (and it may 
well be an error that has been reported before - 
https://github.com/MiKTeX/miktex/issues/921). I will have a look in the 
logs when the new results appear, it may be related.

> The setup, I used (hopefully close to r-devel-windows-x86_64-gcc10-UCRT) was
>
>- Microsoft Windows 10 Enterprise LTSC, 10.0.17763 Build 17763
>- R 4.2.0 Pre Release UCRT3 downloaded today from r-project.org as the 
> only R installation
>- Rtools 4.0.2.0.1 downloaded today from r-project.org as the only Rtools 
> installation
>- For TeX, I installed MiKTeX 21.6 as the only TeX installation.
>- all binaries were put on the PATH environment variable
>
> ——
>
> Now my question: Is this related to CRAN’s r-devel-windows-x86_64-gcc10-UCRT 
> and can that be fixed there? Whom should I contact at CRAN?

In principle, you can always write to the CRAN address and your email 
will be forwarded to the right person. Currently I am running these checks.

Best
Tomas

>
> Thank you in advance,
>
> Stephan
>
>
>
> --
> Dr. Stephan Struckmann
> stephan.struckm...@uni-greifswald.de
> Biomathematiker/Informatiker/Apotheker
> Tel. +49 (0) 3834 - 86 77 83
>
> Institut für Community Medicine
> Walther-Rathenau-Str. 48
> 17475 Greifswald
>
>
> __
> 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] [External] Re: What is a "retired"package?

[Jeff Newmiller]

As you previously quoted:

> plyr is retired: this means only changes necessary to keep it on CRAN will be 
> made.

That excludes bugfixes related to any specific use cases it is not currently 
capable of handling. In other words, if it doesn't handle the data you pass 
along to it from your users, or there turns out to be a security problem (I 
agree, not likely, but remember these agencies don't shade things by "likely") 
then the plyr maintainers aren't promising to fix it. Take it "as-is". This is 
exactly what this "agency" you are being hassled by is concerned about... not 
the label applied to that status.

On September 21, 2021 8:50:32 AM PDT, "Lenth, Russell V" 
 wrote:
>... "I am not fixing this hot mess"??? To the contrary, the README contains a 
>clearly expressed intention to maintain plyr to keep in on CRAN.
>
>RL
>
>-Original Message-
>From: Jeff Newmiller  
>Sent: Tuesday, September 21, 2021 10:36 AM
>To: r-package-devel@r-project.org; Lenth, Russell V ; 
>r-package-devel@r-project.org
>Subject: [External] Re: [R-pkg-devel] What is a "retired"package?
>
>There is nothing official about that term. However, the meaning as intended by 
>the package authors seems pretty clear to me, and if some organization decides 
>not to allow software that is not being maintained to be relied upon then that 
>is their decision. I don't think slapping a different label on "I am not 
>fixing this hot mess" is going to change that organization's stance, and 
>expecting the author to play that game is unreasonable.
>
>Welcome to the downside of package interdependencies. I highly recommend that 
>you migrate away from plyr, either by absorbing the key functions you need 
>from it or by relying on different packages.
>

-- 
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] Re: What is a "retired"package?

[Noah Greifer]

apply() also recently got a 'simplify' argument, which means you request
its output be returned as a list, too (i.e., to replace alply).

Noah

On Tue, Sep 21, 2021 at 12:10 PM Jeff Newmiller 
wrote:

> As you previously quoted:
>
> > plyr is retired: this means only changes necessary to keep it on CRAN
> will be made.
>
> That excludes bugfixes related to any specific use cases it is not
> currently capable of handling. In other words, if it doesn't handle the
> data you pass along to it from your users, or there turns out to be a
> security problem (I agree, not likely, but remember these agencies don't
> shade things by "likely") then the plyr maintainers aren't promising to fix
> it. Take it "as-is". This is exactly what this "agency" you are being
> hassled by is concerned about... not the label applied to that status.
>
> On September 21, 2021 8:50:32 AM PDT, "Lenth, Russell V" <
> russell-le...@uiowa.edu> wrote:
> >... "I am not fixing this hot mess"??? To the contrary, the README
> contains a clearly expressed intention to maintain plyr to keep in on CRAN.
> >
> >RL
> >
> >-Original Message-
> >From: Jeff Newmiller 
> >Sent: Tuesday, September 21, 2021 10:36 AM
> >To: r-package-devel@r-project.org; Lenth, Russell V <
> russell-le...@uiowa.edu>; r-package-devel@r-project.org
> >Subject: [External] Re: [R-pkg-devel] What is a "retired"package?
> >
> >There is nothing official about that term. However, the meaning as
> intended by the package authors seems pretty clear to me, and if some
> organization decides not to allow software that is not being maintained to
> be relied upon then that is their decision. I don't think slapping a
> different label on "I am not fixing this hot mess" is going to change that
> organization's stance, and expecting the author to play that game is
> unreasonable.
> >
> >Welcome to the downside of package interdependencies. I highly recommend
> that you migrate away from plyr, either by absorbing the key functions you
> need from it or by relying on different packages.
> >
>
> --
> 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
>

[[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] [External] Re: What is a "retired"package?

[Lenth, Russell V]

OK. Well, as Noah has pointed out, I can just use apply to do what I need, and 
get plyr out of the picture. 

But for the broader question, Jeff is saying that there really are 700 packages 
that are in potential trouble!

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

Re: [R-pkg-devel] [External] Re: What is a "retired"package?

[Hadley Wickham]

> But for the broader question, Jeff is saying that there really are 700 
> packages that are in potential trouble!

I think that's rather an overstatement of the problem — there's
nothing wrong with plyr; it's just no longer under active development.
If anything, plyr is one of the safest packages to depend upon because
you can know it will never change :)

Hadley

-- 
http://hadley.nz

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

Re: [R-pkg-devel] LaTeX issues on r-devel-windows-x86_64-gcc10-UCRT?

[Struckmann, Stephan]

Dear Thomas,

thank you for your quick reply. I'll consider then writing to the CRAN address 
earler, if I have strong hints that the build/check system may cause a 
warning/error. 

So, I'll wait for the next check-run then. If I can help you in any way with 
fixing the pipelines, just ask... CRAN is doing a great job and we definitley 
benefit strongly from it, so I should be able to find some time to help.

Thank you again, hope we can get this fixed soon,

Greetings

Stephan

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

Re: [R-pkg-devel] [External] Re: What is a "retired"package?

[Jeff Newmiller]

I agree... but trouble is in the eyes of the beholder. If OP's approval process 
requires use of actively-maintained software, then use of code depending on one 
of these "retired"/"superceded" packages could indeed be a problem... for the 
OP. OP cannot expect to be able to impose those requirements on others though.

On September 21, 2021 9:48:28 AM PDT, Hadley Wickham  
wrote:
>> But for the broader question, Jeff is saying that there really are 700 
>> packages that are in potential trouble!
>
>I think that's rather an overstatement of the problem — there's
>nothing wrong with plyr; it's just no longer under active development.
>If anything, plyr is one of the safest packages to depend upon because
>you can know it will never change :)
>
>Hadley
>

-- 
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] Re: What is a "retired"package?

[Lenth, Russell V]

Hadley,

As I suspected, and a good point. But please note that the term "retired" 
causes angst, and it may be good to change that to "superceded" or something 
else.

As a side note, I'll mention that I myself am retired, and I'll claim that that 
does not make me less dependable. But one difference in retirement is that I 
now care less about public embarrassment, such as not knowing that all along, I 
could have used base::apply instead of plyr::aaply.

-Original Message-
From: Hadley Wickham  
Sent: Tuesday, September 21, 2021 11:48 AM
To: Lenth, Russell V 
Cc: Jeff Newmiller ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] [External] Re: What is a "retired"package?

> But for the broader question, Jeff is saying that there really are 700 
> packages that are in potential trouble!

I think that's rather an overstatement of the problem — there's nothing wrong 
with plyr; it's just no longer under active development.
If anything, plyr is one of the safest packages to depend upon because you can 
know it will never change :)

Hadley

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

Re: [R-pkg-devel] [External] Re: What is a "retired"package?

[Hadley Wickham]

Yes, as Lionel said that is why we have changed our terminology to
superseded — we wanted to imply that a retired package was still a
useful member of society, if not working full-time anymore, but most
people seem to think that retired means that we took the package out
behind the shed and put it out of its misery.

Haley

On Tue, Sep 21, 2021 at 1:43 PM Lenth, Russell V
 wrote:
>
> Hadley,
>
> As I suspected, and a good point. But please note that the term "retired" 
> causes angst, and it may be good to change that to "superceded" or something 
> else.
>
> As a side note, I'll mention that I myself am retired, and I'll claim that 
> that does not make me less dependable. But one difference in retirement is 
> that I now care less about public embarrassment, such as not knowing that all 
> along, I could have used base::apply instead of plyr::aaply.
>
> -Original Message-
> From: Hadley Wickham 
> Sent: Tuesday, September 21, 2021 11:48 AM
> To: Lenth, Russell V 
> Cc: Jeff Newmiller ; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] [External] Re: What is a "retired"package?
>
> > But for the broader question, Jeff is saying that there really are 700 
> > packages that are in potential trouble!
>
> I think that's rather an overstatement of the problem — there's nothing wrong 
> with plyr; it's just no longer under active development.
> If anything, plyr is one of the safest packages to depend upon because you 
> can know it will never change :)
>
> Hadley
>
> --
> http://hadley.nz



-- 
http://hadley.nz

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

Re: [R-pkg-devel] [External] Re: What is a "retired"package?

[Viechtbauer, Wolfgang (SP)]

:) That's a fortune nomination on my part.

Best,
Wolfgang

>-Original Message-
>From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
>Of
>Hadley Wickham
>Sent: Tuesday, 21 September, 2021 20:45
>To: Lenth, Russell V
>Cc: r-package-devel@r-project.org
>Subject: Re: [R-pkg-devel] [External] Re: What is a "retired"package?
>
>Yes, as Lionel said that is why we have changed our terminology to
>superseded — we wanted to imply that a retired package was still a
>useful member of society, if not working full-time anymore, but most
>people seem to think that retired means that we took the package out
>behind the shed and put it out of its misery.
>
>Haley
>
>On Tue, Sep 21, 2021 at 1:43 PM Lenth, Russell V
> wrote:
>>
>> Hadley,
>>
>> As I suspected, and a good point. But please note that the term "retired" 
>> causes
>angst, and it may be good to change that to "superceded" or something else.
>>
>> As a side note, I'll mention that I myself am retired, and I'll claim that 
>> that
>does not make me less dependable. But one difference in retirement is that I 
>now
>care less about public embarrassment, such as not knowing that all along, I 
>could
>have used base::apply instead of plyr::aaply.
>>
>> -Original Message-
>> From: Hadley Wickham 
>> Sent: Tuesday, September 21, 2021 11:48 AM
>> To: Lenth, Russell V 
>> Cc: Jeff Newmiller ; r-package-devel@r-project.org
>> Subject: Re: [R-pkg-devel] [External] Re: What is a "retired"package?
>>
>> > But for the broader question, Jeff is saying that there really are 700
>packages that are in potential trouble!
>>
>> I think that's rather an overstatement of the problem — there's nothing wrong
>with plyr; it's just no longer under active development.
>> If anything, plyr is one of the safest packages to depend upon because you 
>> can
>know it will never change :)
>>
>> Hadley
>>
>> --
>> http://hadley.nz
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel