Re: [R-pkg-devel] Etiquette for package submissions that do not automatically pass checks?

2020-08-18 Thread Voeten, C.C.
Dear Ivan,

> Apologies for derailing the thread, but I had a similar problem a few
> months ago [*], found what looks like a different solution but did not
> have time to investigate it further.
> 
> Given that serialize() does not send package namespaces over the wire
> [**], why would it be a bad idea to pass actual functions (instead of
> character strings naming functions) to parallel::parLapply and friends?
> This seems to avoid the need to export the worker functions or use :::
> in calls to parallel functions from package functions. Unless I am
> missing something, which I probably am.

No worries, these issues are also what this mailing list is for! I've meanwhile 
heard back from Uwe that I should resubmit after the 24th, and that he still 
would like the warning to go away. Your suggestion certainly makes sense, but 
it would require a rewrite of some delicate parts. Fortunately, I was already 
passing a parameter list around anyway, so I can just add those functions in 
that list, and I'll probably end up indeed taking that approach. Thank you for 
the suggestion! It does feel like an awful hack, though, given that the 
language supports doing this in a clean way using the ::: operator. But I also 
understand that CRAN want to impose certain limitations to discourage bad 
practices, and I trust their judgment that ::: is one of those.

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


Re: [R-pkg-devel] Etiquette for package submissions that do not automatically pass checks?

2020-08-17 Thread Ivan Krylov
Dear Cesko,

On Fri, 14 Aug 2020 21:08:55 +0200
Cesko Voeten  wrote:

> The package contains functionality to run on cluster nodes that were
> set up by the user and needs to access its own internal functions
> from there.

Apologies for derailing the thread, but I had a similar problem a few
months ago [*], found what looks like a different solution but did not
have time to investigate it further.

Given that serialize() does not send package namespaces over the wire
[**], why would it be a bad idea to pass actual functions (instead of
character strings naming functions) to parallel::parLapply and friends?
This seems to avoid the need to export the worker functions or use :::
in calls to parallel functions from package functions. Unless I am
missing something, which I probably am.

-- 
Best regards,
Ivan

[*] https://stat.ethz.ch/pipermail/r-package-devel/2020q2/005468.html

[**]
https://cran.r-project.org/doc/manuals/r-release/R-ints.html#Serialization-Formats

"Package and namespace environments are written with pseudo-SEXPTYPEs
followed by the name."

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


Re: [R-pkg-devel] Etiquette for package submissions that do not automatically pass checks?

2020-08-15 Thread Cesko Voeten

Duncan, Joshua,

Thanks for the feedback. I had indeed forgotten to increment the version 
number, so that may explain it. I'll give it until a few days after the 24th, 
and then just resubmit with a new version number.

Also, thanks for introducing me to the foghorn package, I wasn't aware of it 
before.

Best,
Cesko

Op 14-08-2020 om 22:31 schreef Joshua Ulrich:

On Fri, Aug 14, 2020 at 2:54 PM Duncan Murdoch  wrote:


On 14/08/2020 3:08 p.m., Cesko Voeten wrote:

A while ago, I submitted an update to my package 'buildmer' that does not pass 
R CMD check. This is deliberate. The package contains functionality to run on 
cluster nodes that were set up by the user and needs to access its own internal 
functions from there. In previous versions of the package, I had maintained a 
list of those functions and clusterExport()ed them, but that had the side 
effect of overwriting any same-named user objects on the user-provided cluster 
nodes, which I thought was poor form. The update therefore accesses these 
functions using ':::', which triggers a check warning.

I thought the etiquette was to explain this in the 'Comments' box when 
submitting, but this gave me the same automated message that the package does 
not pass checks and that I should fix it or reply-all and explain. This led me 
to believe that I should not have used the 'Comments' box for this purpose, 
hence I resubmitted the package leaving the comments box empty, and I 
replied-all to the subsequent e-mail I got with an explanation similar to the 
above.


It seems to me that what you should have done is "reply-all and
explain", as the automated message said.


It has now been a while since I sent that e-mail (ten days), and I have yet to 
hear back. I was wondering if the message had gotten lost, if they simply 
haven't gotten around to it yet (I have no idea how much mail they receive on a 
daily basis, but I'd think it's a lot more than I do), or if I should have 
handled this differently. Only CRAN can answer the first two questions, but 
before I bother them: was this the correct procedure, or should I simply have 
done something differently?



You can see the state of your submission using the foghorn package.
cran_incoming("buildmer") currently shows your package is in the
"archive", which means "package rejected: it does not pass the checks
cleanly and the problems are unlikely to be false positives".

I only see version 1.7 there, which may indicate that you resubmitted
exactly the same package (down to the version number).  As the
instructions at
https://cran.r-project.org/web/packages/policies.html#Re_002dsubmission
say, "Increasing the version number at each submission reduces confusion
so is preferred even when a previous submission was not accepted."

What I'd suggest now is that you do nothing more for a day or two,
because CRAN members who aren't on holiday might read and respond to
your message.  If you don't hear anything, then I'd start over again,
with a new version number, and an explanation in the comments, and
likely a followup reply-all.


You have more than a few days.  As it says on CRAN:
"CRAN submission is offline from Aug 14 to Aug 24, 2020 (CRAN team
vacation and maintainance work)"


Alternatively, you could export those troublesome functions from your
package but document them as for internal use only.  Renaming them with
a name starting with "." will make them harder for users to stumble
upon, but you can still access them using buildmer::.something, you
shouldn't need clusterExport(). Then you will meet the technical
requirement and not need any explanation.

Duncan Murdoch

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






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


Re: [R-pkg-devel] Etiquette for package submissions that do not automatically pass checks?

2020-08-14 Thread Joshua Ulrich
On Fri, Aug 14, 2020 at 2:54 PM Duncan Murdoch  wrote:
>
> On 14/08/2020 3:08 p.m., Cesko Voeten wrote:
> > A while ago, I submitted an update to my package 'buildmer' that does not 
> > pass R CMD check. This is deliberate. The package contains functionality to 
> > run on cluster nodes that were set up by the user and needs to access its 
> > own internal functions from there. In previous versions of the package, I 
> > had maintained a list of those functions and clusterExport()ed them, but 
> > that had the side effect of overwriting any same-named user objects on the 
> > user-provided cluster nodes, which I thought was poor form. The update 
> > therefore accesses these functions using ':::', which triggers a check 
> > warning.
> >
> > I thought the etiquette was to explain this in the 'Comments' box when 
> > submitting, but this gave me the same automated message that the package 
> > does not pass checks and that I should fix it or reply-all and explain. 
> > This led me to believe that I should not have used the 'Comments' box for 
> > this purpose, hence I resubmitted the package leaving the comments box 
> > empty, and I replied-all to the subsequent e-mail I got with an explanation 
> > similar to the above.
>
> It seems to me that what you should have done is "reply-all and
> explain", as the automated message said.
>
> > It has now been a while since I sent that e-mail (ten days), and I have yet 
> > to hear back. I was wondering if the message had gotten lost, if they 
> > simply haven't gotten around to it yet (I have no idea how much mail they 
> > receive on a daily basis, but I'd think it's a lot more than I do), or if I 
> > should have handled this differently. Only CRAN can answer the first two 
> > questions, but before I bother them: was this the correct procedure, or 
> > should I simply have done something differently?
> >
>
> You can see the state of your submission using the foghorn package.
> cran_incoming("buildmer") currently shows your package is in the
> "archive", which means "package rejected: it does not pass the checks
> cleanly and the problems are unlikely to be false positives".
>
> I only see version 1.7 there, which may indicate that you resubmitted
> exactly the same package (down to the version number).  As the
> instructions at
> https://cran.r-project.org/web/packages/policies.html#Re_002dsubmission
> say, "Increasing the version number at each submission reduces confusion
> so is preferred even when a previous submission was not accepted."
>
> What I'd suggest now is that you do nothing more for a day or two,
> because CRAN members who aren't on holiday might read and respond to
> your message.  If you don't hear anything, then I'd start over again,
> with a new version number, and an explanation in the comments, and
> likely a followup reply-all.
>
You have more than a few days.  As it says on CRAN:
"CRAN submission is offline from Aug 14 to Aug 24, 2020 (CRAN team
vacation and maintainance work)"

> Alternatively, you could export those troublesome functions from your
> package but document them as for internal use only.  Renaming them with
> a name starting with "." will make them harder for users to stumble
> upon, but you can still access them using buildmer::.something, you
> shouldn't need clusterExport(). Then you will meet the technical
> requirement and not need any explanation.
>
> Duncan Murdoch
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com

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


Re: [R-pkg-devel] Etiquette for package submissions that do not automatically pass checks?

2020-08-14 Thread Duncan Murdoch

On 14/08/2020 3:08 p.m., Cesko Voeten wrote:

A while ago, I submitted an update to my package 'buildmer' that does not pass 
R CMD check. This is deliberate. The package contains functionality to run on 
cluster nodes that were set up by the user and needs to access its own internal 
functions from there. In previous versions of the package, I had maintained a 
list of those functions and clusterExport()ed them, but that had the side 
effect of overwriting any same-named user objects on the user-provided cluster 
nodes, which I thought was poor form. The update therefore accesses these 
functions using ':::', which triggers a check warning.

I thought the etiquette was to explain this in the 'Comments' box when 
submitting, but this gave me the same automated message that the package does 
not pass checks and that I should fix it or reply-all and explain. This led me 
to believe that I should not have used the 'Comments' box for this purpose, 
hence I resubmitted the package leaving the comments box empty, and I 
replied-all to the subsequent e-mail I got with an explanation similar to the 
above.


It seems to me that what you should have done is "reply-all and 
explain", as the automated message said.



It has now been a while since I sent that e-mail (ten days), and I have yet to 
hear back. I was wondering if the message had gotten lost, if they simply 
haven't gotten around to it yet (I have no idea how much mail they receive on a 
daily basis, but I'd think it's a lot more than I do), or if I should have 
handled this differently. Only CRAN can answer the first two questions, but 
before I bother them: was this the correct procedure, or should I simply have 
done something differently?



You can see the state of your submission using the foghorn package. 
cran_incoming("buildmer") currently shows your package is in the 
"archive", which means "package rejected: it does not pass the checks 
cleanly and the problems are unlikely to be false positives".


I only see version 1.7 there, which may indicate that you resubmitted 
exactly the same package (down to the version number).  As the 
instructions at 
https://cran.r-project.org/web/packages/policies.html#Re_002dsubmission 
say, "Increasing the version number at each submission reduces confusion 
so is preferred even when a previous submission was not accepted."


What I'd suggest now is that you do nothing more for a day or two, 
because CRAN members who aren't on holiday might read and respond to 
your message.  If you don't hear anything, then I'd start over again, 
with a new version number, and an explanation in the comments, and 
likely a followup reply-all.


Alternatively, you could export those troublesome functions from your 
package but document them as for internal use only.  Renaming them with 
a name starting with "." will make them harder for users to stumble 
upon, but you can still access them using buildmer::.something, you 
shouldn't need clusterExport(). Then you will meet the technical 
requirement and not need any explanation.


Duncan Murdoch

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