Re: [R-pkg-devel] Re-building vignettes had CPU time 9.2 times elapsed time

[Tim Taylor]

I’m definitely sympathetic to both sides but have come around to the view of 
Greg, Dirk et al. It seems sensible to have a default that benefits the 
majority of “normal” users and require explicit action in shared environments 
not vice-versa.

That is not to say that data.table could not do better with it’s heuristics 
(e.g. respecting CGroups settings as raised by Henrik in 
https://github.com/Rdatatable/data.table/issues/5620) but the current defaults 
(50%) seem reasonable for, dare I say, most users.

Tim

> On 26 Aug 2023, at 03:20, Greg Hunt  wrote:
> 
> The question should be, in how many cases is the current behaviour a
> problem?  In a shared environment, sure, you have to be more careful.  I'd
> say don't let the teenagers in there. The CRAN build server does need to do
> something to protect itself and I don't greatly mind the 2 thread limit, I
> implemented it by hand in my examples and didn't think about it
> afterwards.  On most 8, 16 or 32 way environments, dedicated or
> semi-dedicated to a particular workload, the defaults make some level of
> sense and they are probably most of the use cases.  Protecting high
> processor count environments from people who don't know what they are doing
> would seem to be a mismatch between the people and the environment, not so
> much a matter of software.
> 
>> On Sat, 26 Aug 2023 at 11:49, Jeff Newmiller 
>> wrote:
>> 
>> You have a really bizarre way of twisting what others are saying, Dirk. I
>> have seen no-one here saying 'limit R to 2 threads' except for you, as a
>> way to paint opposing views to be absurd.
>> 
>> What _is_ being said is that users need to be in control_, but _the
>> default needs to do least harm_ until those users take responsibility for
>> that control. Do not turn the throttle up until the user is prepared for
>> the consequences. Trying to subvert that responsibility into packages by
>> default is going to make more trouble than giving the people using those
>> packages simple examples of how to take that control.
>> 
>> A similar problem happens when users discover .Rprofile and insert all
>> those pesky library statements into it, making their scripts
>> irreproducible. If data.table made a warp10() function that activated this
>> current default performance setting then the user would be clearly at fault
>> for using it in an inappropriate environment like a shared HPC or the CRAN
>> servers. Don't put a brick on the accelerator of a teenager's car before
>> they even figure out where the brakes are.
>> 
>>> On August 25, 2023 6:17:04 PM PDT, Dirk Eddelbuettel 
>>> wrote:
>>> 
 On 26 August 2023 at 12:05, Simon Urbanek wrote:
>>> | In reality it's more people running R on their laptops vs the rest of
>> the world.
>>> 
>>> My point was that we also have 'single user on really Yuge workstation'.
>>> 
>>> Plus we all know that those users are often not sysadmins, and do not have
>>> our levels of accumulated systems knowledge.
>>> 
>>> So we should give _more_ power by default, not less.
>>> 
>>> | [...] they will always be saying blatantly false things like "R is not
>> for large data"
>>> 
>>> By limiting R (and/or packages) to two threads we will only get more of
>>> these.  Our collective call.
>>> 
>>> This whole thread is pretty sad, actually.
>>> 
>>> Dirk
>>> 
>> 
>> --
>> 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

[[alternative HTML version deleted]]

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

[R-pkg-devel] What to do when a package is archived from CRAN

[SHIMA Tatsuya]

Hi,

I noticed that my submitted package `prqlr` 0.5.0 was archived from CRAN 
on 2023-08-19.



I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only 
received word from CRAN that it passed the automated release process. 

So I was very surprised to find out after I returned from my trip that 
this was archived.


The CRAN page says "Archived on 2023-08-19 for policy violation. " but I 
don't know what exactly was the problem.
I have no idea what more to fix as I believe I have solved all the 
problems when I submitted 0.5.0.


Is there any way to know what exactly was the problem?
(I thought I sent an e-mail to CRAN 5 days ago but have not yet received 
an answer, so I decided to ask my question on this mailing list, 
thinking that there is a possibility that there will be no answer to my 
e-mail, although I may have to wait a few weeks for an answer. My 
apologies if this idea is incorrect.)


Best,
Tatsuya

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

Re: [R-pkg-devel] What to do when a package is archived from CRAN

[Sarah Goslee]

Hi,

You can generally see what the reason is from the archive page, where it says:
A summary of the most recent check results can be obtained from the
check results archive.

On that page, 
https://cran-archive.r-project.org/web/checks/2023/2023-08-19_check_results_prqlr.html
is the note:

Version: 0.5.0
Check: installed package size
Result: NOTE
 installed size is 18.5Mb
 sub-directories of 1Mb or more:
 libs 18.2Mb

This is too big for CRAN, see
https://cran.r-project.org/web/packages/policies.html quoted here:

Packages should be of the minimum necessary size. Reasonable
compression should be used for data (not just .rda files) and PDF
documentation: CRAN will if necessary pass the latter through qpdf.

As a general rule, neither data nor documentation should exceed 5MB
(which covers several books). A CRAN package is not an appropriate way
to distribute course notes, and authors will be asked to trim their
documentation to a maximum of 5MB.

Where a large amount of data is required (even after compression),
consideration should be given to a separate data-only package which
can be updated only rarely (since older versions of packages are
archived in perpetuity).

Similar considerations apply to other forms of “data”, e.g., .jar files.

Source package tarballs should if possible not exceed 10MB. It is much
preferred that third-party source software should be included within
the package (as e.g. a vendor.tar.xz file) than be downloaded at
installation: if this requires a larger tarball a modestly increased
limit can be requested at submission.

Sarah

On Sat, Aug 26, 2023 at 4:26 PM SHIMA Tatsuya  wrote:
>
> Hi,
>
> I noticed that my submitted package `prqlr` 0.5.0 was archived from CRAN
> on 2023-08-19.
> 
>
> I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only
> received word from CRAN that it passed the automated release process.
> 
> So I was very surprised to find out after I returned from my trip that
> this was archived.
>
> The CRAN page says "Archived on 2023-08-19 for policy violation. " but I
> don't know what exactly was the problem.
> I have no idea what more to fix as I believe I have solved all the
> problems when I submitted 0.5.0.
>
> Is there any way to know what exactly was the problem?
> (I thought I sent an e-mail to CRAN 5 days ago but have not yet received
> an answer, so I decided to ask my question on this mailing list,
> thinking that there is a possibility that there will be no answer to my
> e-mail, although I may have to wait a few weeks for an answer. My
> apologies if this idea is incorrect.)
>
> Best,
> Tatsuya
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
Sarah Goslee (she/her)
http://www.sarahgoslee.com

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

Re: [R-pkg-devel] What to do when a package is archived from CRAN

[Ivan Krylov]

On Sat, 26 Aug 2023 11:46:44 +0900
SHIMA Tatsuya  wrote:

> I noticed that my submitted package `prqlr` 0.5.0 was archived from
> CRAN on 2023-08-19.
> 
> 
> I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only 
> received word from CRAN that it passed the automated release process. 

Sarah gave a good guess (although there are CRAN packages containing
C++ and Rust code with NOTEs about size of their libs, 18.2Mb is still
a lot), though I do find it strange that you didn't receive anything
from CRAN prior to having your package archived. I don't think I ever
had problems with e-mails being delivered from CRAN to GMail, but we
can't rule that out.

You've obviously made an effort to follow the Rust policy, and I don't
see any obvious problems with this part of the package, although I
haven't tried it myself to verify the installation working offline from
bundled source code.

You've also made an effort to list all the authors of the code
comprising your package in inst/AUTHORS, which is the right thing to do
to avoid making the list of authors in DESCRIPTION long enough to be
unreadable.

You licensed the package as MIT. Are your dependencies compatible with
MIT? All direct dependencies of your Rust code seem to be licensed
under either MIT or Apache-2.0, which seems to be compatible. You named
the copyright holder of your package as "prqlr authors", which may be a
problem. (I think I saw it somewhere that for MIT license, CRAN prefers
the copyright holder to be some kind of legal entity: either the legal
name of a person, or a company, or something like that.)

Could the Rust code or any of the dependencies accidentally write under
the user's home directory or take over the terminal or something like
that?

We might need a response from CRAN after all.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] What to do when a package is archived from CRAN

[Simon Urbanek]

Tatsuya,

What you do is contact CRAN. I don't think anyone here can answer your 
question, only CRAN can, so ask there.

Generally, packages with sufficiently many Rust dependencies have to be handled 
manually as they break the size limit, so auto-rejections are normal. Archival 
is unusual, but it may have fallen through the cracks - but the way to find out 
is to ask.

One related issue with respect to CRAN policies that I don't see a good 
solution for is that inst/AUTHORS is patently unhelpful, because most of them 
say "foo (version ..): foo authors" with no contact, or real names or any 
links. That seems to be a problem stemming from the Rust community as there 
doesn't seem to be any accountability with respect to ownership and 
attribution. I don't know if it's because it's assumed that GitHub history is 
the canonical source with the provenance, but that gets lost when pulled into 
the package.

Cheers,
Simon

PS: Your README says "(Rust 1.65 or later)", but the version condition is 
missing from SystemRequirements.


> On Aug 26, 2023, at 2:46 PM, SHIMA Tatsuya  wrote:
> 
> Hi,
> 
> I noticed that my submitted package `prqlr` 0.5.0 was archived from CRAN on 
> 2023-08-19.
> 
> 
> I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only received 
> word from CRAN that it passed the automated release process. 
> 
> So I was very surprised to find out after I returned from my trip that this 
> was archived.
> 
> The CRAN page says "Archived on 2023-08-19 for policy violation. " but I 
> don't know what exactly was the problem.
> I have no idea what more to fix as I believe I have solved all the problems 
> when I submitted 0.5.0.
> 
> Is there any way to know what exactly was the problem?
> (I thought I sent an e-mail to CRAN 5 days ago but have not yet received an 
> answer, so I decided to ask my question on this mailing list, thinking that 
> there is a possibility that there will be no answer to my e-mail, although I 
> may have to wait a few weeks for an answer. My apologies if this idea is 
> incorrect.)
> 
> Best,
> Tatsuya
> 
> __
> 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] Re-building vignettes had CPU time 9.2 times elapsed time

[Greg Hunt]

Tim,
I think that things like data.table have a different set of problems
depending on the environment.  Working out what the right degree of
parallelism for an IO workload is is a hard question that depends on the
characteristics of the IO subsystem, the characteristics of the dataset and
on what problem you really have (really how much its worth spending to
achieve an optimal answer).  It would be interesting to see how well
data.table would do with several tens of threads on several tens of
processors reading a file, I suspect it might not be pretty (coordination
overheads could be large relative to the actual gains from IO
parallelism), but its not a subject I've looked at.  It would not
surprise me if the right answer was to cap the number of threads, but that
cap would probably still be higher than the usual number of processors in
the average physical or virtual box.  This stuff is not easy and its
saturated with "it depends" answers.  The underlying problem here is that
to get optimal or optimal-enough behaviour, a 96-way or more box
will require different configuration of the software to an 8 or 16-way VM.


Greg

On Sat, 26 Aug 2023 at 18:15, Tim Taylor 
wrote:

> I’m definitely sympathetic to both sides but have come around to the view
> of Greg, Dirk et al. It seems sensible to have a default that benefits the
> majority of “normal” users and require explicit action in shared
> environments not vice-versa.
>
> That is not to say that data.table could not do better with it’s
> heuristics (e.g. respecting CGroups settings as raised by Henrik in
> https://github.com/Rdatatable/data.table/issues/5620) but the current
> defaults (50%) seem reasonable for, dare I say, most users.
>
> Tim
>
> On 26 Aug 2023, at 03:20, Greg Hunt  wrote:
>
> The question should be, in how many cases is the current behaviour a
> problem?  In a shared environment, sure, you have to be more careful.  I'd
> say don't let the teenagers in there. The CRAN build server does need to do
> something to protect itself and I don't greatly mind the 2 thread limit, I
> implemented it by hand in my examples and didn't think about it
> afterwards.  On most 8, 16 or 32 way environments, dedicated or
> semi-dedicated to a particular workload, the defaults make some level of
> sense and they are probably most of the use cases.  Protecting high
> processor count environments from people who don't know what they are doing
> would seem to be a mismatch between the people and the environment, not so
> much a matter of software.
>
> On Sat, 26 Aug 2023 at 11:49, Jeff Newmiller 
> wrote:
>
> You have a really bizarre way of twisting what others are saying, Dirk. I
>
> have seen no-one here saying 'limit R to 2 threads' except for you, as a
>
> way to paint opposing views to be absurd.
>
>
> What _is_ being said is that users need to be in control_, but _the
>
> default needs to do least harm_ until those users take responsibility for
>
> that control. Do not turn the throttle up until the user is prepared for
>
> the consequences. Trying to subvert that responsibility into packages by
>
> default is going to make more trouble than giving the people using those
>
> packages simple examples of how to take that control.
>
>
> A similar problem happens when users discover .Rprofile and insert all
>
> those pesky library statements into it, making their scripts
>
> irreproducible. If data.table made a warp10() function that activated this
>
> current default performance setting then the user would be clearly at fault
>
> for using it in an inappropriate environment like a shared HPC or the CRAN
>
> servers. Don't put a brick on the accelerator of a teenager's car before
>
> they even figure out where the brakes are.
>
>
> On August 25, 2023 6:17:04 PM PDT, Dirk Eddelbuettel 
>
> wrote:
>
>
> On 26 August 2023 at 12:05, Simon Urbanek wrote:
>
> | In reality it's more people running R on their laptops vs the rest of
>
> the world.
>
>
> My point was that we also have 'single user on really Yuge workstation'.
>
>
> Plus we all know that those users are often not sysadmins, and do not have
>
> our levels of accumulated systems knowledge.
>
>
> So we should give _more_ power by default, not less.
>
>
> | [...] they will always be saying blatantly false things like "R is not
>
> for large data"
>
>
> By limiting R (and/or packages) to two threads we will only get more of
>
> these.  Our collective call.
>
>
> This whole thread is pretty sad, actually.
>
>
> Dirk
>
>
>
> --
>
> 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
>
>

[[alternative HTML version deleted]]

___

Re: [R-pkg-devel] What to do when a package is archived from CRAN

[Hiroaki Yutani]

Simon,

> it's assumed that GitHub history is the canonical source with the
provenance, but that gets lost when pulled into the package.

No, not GitHub. You can usually find the ownership on crates.io. So, if you
want a target to blame, it's probably just a problem of the script to
auto-generate inst/AUTHORS in this specific case. But, clearly, Rust's
ecosystem works soundly under the existence of crates.io, so I think this
is the same kind of pain which you would feel if you use R without CRAN.

Sorry for nitpicking.

Best,
Yutani

2023年8月27日(日) 6:57 Simon Urbanek :

> Tatsuya,
>
> What you do is contact CRAN. I don't think anyone here can answer your
> question, only CRAN can, so ask there.
>
> Generally, packages with sufficiently many Rust dependencies have to be
> handled manually as they break the size limit, so auto-rejections are
> normal. Archival is unusual, but it may have fallen through the cracks -
> but the way to find out is to ask.
>
> One related issue with respect to CRAN policies that I don't see a good
> solution for is that inst/AUTHORS is patently unhelpful, because most of
> them say "foo (version ..): foo authors" with no contact, or real names or
> any links. That seems to be a problem stemming from the Rust community as
> there doesn't seem to be any accountability with respect to ownership and
> attribution. I don't know if it's because it's assumed that GitHub history
> is the canonical source with the provenance, but that gets lost when pulled
> into the package.
>
> Cheers,
> Simon
>
> PS: Your README says "(Rust 1.65 or later)", but the version condition is
> missing from SystemRequirements.
>
>
> > On Aug 26, 2023, at 2:46 PM, SHIMA Tatsuya  wrote:
> >
> > Hi,
> >
> > I noticed that my submitted package `prqlr` 0.5.0 was archived from CRAN
> on 2023-08-19.
> > 
> >
> > I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only
> received word from CRAN that it passed the automated release process. <
> https://github.com/eitsupi/prqlr/pull/161>
> > So I was very surprised to find out after I returned from my trip that
> this was archived.
> >
> > The CRAN page says "Archived on 2023-08-19 for policy violation. " but I
> don't know what exactly was the problem.
> > I have no idea what more to fix as I believe I have solved all the
> problems when I submitted 0.5.0.
> >
> > Is there any way to know what exactly was the problem?
> > (I thought I sent an e-mail to CRAN 5 days ago but have not yet received
> an answer, so I decided to ask my question on this mailing list, thinking
> that there is a possibility that there will be no answer to my e-mail,
> although I may have to wait a few weeks for an answer. My apologies if this
> idea is incorrect.)
> >
> > Best,
> > Tatsuya
> >
> > __
> > 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] What to do when a package is archived from CRAN

[Simon Urbanek]

Yutani,


> On Aug 27, 2023, at 2:19 PM, Hiroaki Yutani  wrote:
> 
> Simon,
> 
> > it's assumed that GitHub history is the canonical source with the 
> > provenance, but that gets lost when pulled into the package.
> 
> No, not GitHub. You can usually find the ownership on crates.io 
> . So, if you want a target to blame, it's probably just a 
> problem of the script to auto-generate inst/AUTHORS in this specific case. 
> But, clearly, Rust's ecosystem works soundly under the existence of crates.io 
> , so I think this is the same kind of pain which you would 
> feel if you use R without CRAN.
> 

Can you elaborate? I have not found anything that would have a list of authors 
in the sources. I fully agree that I know nothing about it, but even if you use 
R without CRAN, each package contains that information in the DESCRIPTION file 
since it's so crucial. So are you saying you have to use crates.io and do some 
extra step during the (misnamed) "vendor" step? (I didn't see the submitted tar 
ball of plqrl and its release on GitHub is not the actual package so can't 
check - thus just trying reverse-engineer what happens by looking at the 
dependencies which leads to GitHub).


> Sorry for nitpicking.
> 

Sure, good to get the fact straight.

Cheers,
Simon



> Best,
> Yutani
> 
> 2023年8月27日(日) 6:57 Simon Urbanek  >:
> Tatsuya,
> 
> What you do is contact CRAN. I don't think anyone here can answer your 
> question, only CRAN can, so ask there.
> 
> Generally, packages with sufficiently many Rust dependencies have to be 
> handled manually as they break the size limit, so auto-rejections are normal. 
> Archival is unusual, but it may have fallen through the cracks - but the way 
> to find out is to ask.
> 
> One related issue with respect to CRAN policies that I don't see a good 
> solution for is that inst/AUTHORS is patently unhelpful, because most of them 
> say "foo (version ..): foo authors" with no contact, or real names or any 
> links. That seems to be a problem stemming from the Rust community as there 
> doesn't seem to be any accountability with respect to ownership and 
> attribution. I don't know if it's because it's assumed that GitHub history is 
> the canonical source with the provenance, but that gets lost when pulled into 
> the package.
> 
> Cheers,
> Simon
> 
> PS: Your README says "(Rust 1.65 or later)", but the version condition is 
> missing from SystemRequirements.
> 
> 
> > On Aug 26, 2023, at 2:46 PM, SHIMA Tatsuya  > > wrote:
> > 
> > Hi,
> > 
> > I noticed that my submitted package `prqlr` 0.5.0 was archived from CRAN on 
> > 2023-08-19.
> >  > >
> > 
> > I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only received 
> > word from CRAN that it passed the automated release process. 
> >  > >
> > So I was very surprised to find out after I returned from my trip that this 
> > was archived.
> > 
> > The CRAN page says "Archived on 2023-08-19 for policy violation. " but I 
> > don't know what exactly was the problem.
> > I have no idea what more to fix as I believe I have solved all the problems 
> > when I submitted 0.5.0.
> > 
> > Is there any way to know what exactly was the problem?
> > (I thought I sent an e-mail to CRAN 5 days ago but have not yet received an 
> > answer, so I decided to ask my question on this mailing list, thinking that 
> > there is a possibility that there will be no answer to my e-mail, although 
> > I may have to wait a few weeks for an answer. My apologies if this idea is 
> > incorrect.)
> > 
> > Best,
> > Tatsuya
> > 
> > __
> > 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] What to do when a package is archived from CRAN

[Hiroaki Yutani]

Simon,

Ok, let's take a look at a real example. The first item of inst/AUTHORS of
prqlr (GitHub version) is this:

addr2line (version 0.20.0):
  addr2line authors

You can find addr2line's owners on crates.io [1], while its manifest file
(Cargo.toml) [2] doesn't contain the names of its owners or authors. In
Rust's manifest, the "authors" field is optional [3] unlike R. You might
argue "owners" is not the same as "authors," but at least crates.io
provides the names of those who are responsible for the crate.

Let's go back to your question.

> So are you saying you have to use crates.io and do some extra step during
the (misnamed) "vendor" step?

"cargo vendor" doesn't take care of generating the list of authors, so it's
not "during the vender step." It has to be done separately anyway. I was
just saying you **can** use crates.io in that step instead of searching for
the authors manually one by one (or filling it with "foo authors" when the
manifest file doesn't contain any names).

That said, I agree with you in general that the Rust community is
relatively loose about authorship and licensing when compared with R. I
don't think it's necessarily a problem, but the impedance mismatch is a
headache. I was just trying to point out this part of your opinion

> the Rust community as there doesn't seem to be any accountability with
respect to ownership and attribution.

was not quite true. I hope the R community and the Rust community have
respect for each other.

Best,
Yutani

[1]: https://crates.io/crates/addr2line
[2]: https://github.com/gimli-rs/addr2line/blob/0.20.0/Cargo.toml
[3]:
https://doc.rust-lang.org/cargo/reference/manifest.html#the-authors-field


2023年8月27日(日) 12:07 Simon Urbanek :

> Yutani,
>
>
> On Aug 27, 2023, at 2:19 PM, Hiroaki Yutani  wrote:
>
> Simon,
>
> > it's assumed that GitHub history is the canonical source with the
> provenance, but that gets lost when pulled into the package.
>
> No, not GitHub. You can usually find the ownership on crates.io. So, if
> you want a target to blame, it's probably just a problem of the script to
> auto-generate inst/AUTHORS in this specific case. But, clearly, Rust's
> ecosystem works soundly under the existence of crates.io, so I think this
> is the same kind of pain which you would feel if you use R without CRAN.
>
>
> Can you elaborate? I have not found anything that would have a list of
> authors in the sources. I fully agree that I know nothing about it, but
> even if you use R without CRAN, each package contains that information in
> the DESCRIPTION file since it's so crucial. So are you saying you have to
> use crates.io and do some extra step during the (misnamed) "vendor" step?
> (I didn't see the submitted tar ball of plqrl and its release on GitHub is
> not the actual package so can't check - thus just trying reverse-engineer
> what happens by looking at the dependencies which leads to GitHub).
>
>
> Sorry for nitpicking.
>
>
> Sure, good to get the fact straight.
>
> Cheers,
> Simon
>
>
>
> Best,
> Yutani
>
> 2023年8月27日(日) 6:57 Simon Urbanek :
>
>> Tatsuya,
>>
>> What you do is contact CRAN. I don't think anyone here can answer your
>> question, only CRAN can, so ask there.
>>
>> Generally, packages with sufficiently many Rust dependencies have to be
>> handled manually as they break the size limit, so auto-rejections are
>> normal. Archival is unusual, but it may have fallen through the cracks -
>> but the way to find out is to ask.
>>
>> One related issue with respect to CRAN policies that I don't see a good
>> solution for is that inst/AUTHORS is patently unhelpful, because most of
>> them say "foo (version ..): foo authors" with no contact, or real names or
>> any links. That seems to be a problem stemming from the Rust community as
>> there doesn't seem to be any accountability with respect to ownership and
>> attribution. I don't know if it's because it's assumed that GitHub history
>> is the canonical source with the provenance, but that gets lost when pulled
>> into the package.
>>
>> Cheers,
>> Simon
>>
>> PS: Your README says "(Rust 1.65 or later)", but the version condition is
>> missing from SystemRequirements.
>>
>>
>> > On Aug 26, 2023, at 2:46 PM, SHIMA Tatsuya  wrote:
>> >
>> > Hi,
>> >
>> > I noticed that my submitted package `prqlr` 0.5.0 was archived from
>> CRAN on 2023-08-19.
>> > > >
>> >
>> > I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only
>> received word from CRAN that it passed the automated release process. <
>> https://github.com/eitsupi/prqlr/pull/161>
>> > So I was very surprised to find out after I returned from my trip that
>> this was archived.
>> >
>> > The CRAN page says "Archived on 2023-08-19 for policy violation. " but
>> I don't know what exactly was the problem.
>> > I have no idea what more to fix as I believe I have solved all the
>> problems when I submitted 0.5.0.
>> >
>> > Is there a