[R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0

Stefan Lenz IMBI |enz @end|ng |rom |mb|@un|-|re|burg@de
Thu Apr 9 10:41:27 CEST 2020 

It is important for me to get my package into CRAN.
I haven't gotten any answer from the CRAN maintainers. I already tried to submit a version of the package before some months and haven't gotten any reply then.
The replies you gave me (thanks to all engaged in the discussion) were mixed.
I still think that the library-like import is a good feature, but if it is not possible to get this package on CRAN with it, I will change it with returning an environment like reticulate.
My question now is:
So what would be the process how to proceed?
Is there anybody who can make a decision in such cases?
Or do I make this decision myself after I lost hope that it will be accepted the way it is now?

Stefan

 
----------------ursprüngliche Nachricht-----------------
Von: Jeff Newmiller [jdnewmil using dcn.davis.ca.us]
An: Stefan Lenz IMBI [lenz using imbi.uni-freiburg.de], r-package-devel using r-project.org, Duncan Murdoch [murdoch.duncan using gmail.com]
Datum: Tue, 07 Apr 2020 09:52:52 -0700
-------------------------------------------------
 
 
> I did not say "interfere"... I said "problems with consistency". I don't think 
> your wholesale import of functions without corresponding help pages is 
> consistent with the normal use of R, which will make reading R code written with 
> this mechanism in place a painful source of trouble for help forums.
> 
> On the other hand, if the code is prefaced with an environment name then there will 
> be no expectation that a help page should exist on the part of someone reading that 
> code for the first time. (It will be no less obscure, but at least it won't be 
> misleading.)
> 
> On April 7, 2020 9:40:02 AM PDT, Stefan Lenz IMBI <lenz using imbi.uni-freiburg.de> 
> wrote:
>>Thank you very much for your comment. 
>>Could you elaborate how you think that it could interfere with the help
>>system?
>>I haven't yet connected the Julia help with the R help, as the R help
>>system is quite complex and RStudio handles it again differently. So
>>it's simply like the functions were declared on the command line. They
>>have no help.
>>A simply way to print the help for a Julia function, e.g. the function
>>"first", is to call
>> juliaEval("@doc first")
>>This then simply prints the output on the command line.
>>
>> 
>>----------------ursprüngliche Nachricht-----------------
>>Von: Jeff Newmiller [jdnewmil using dcn.davis.ca.us]
>>An: r-package-devel using r-project.org, Duncan Murdoch
>>[murdoch.duncan using gmail.com], Stefan Lenz IMBI
>>[lenz using imbi.uni-freiburg.de]
>>Datum: Mon, 06 Apr 2020 10:51:53 -0700
>>-------------------------------------------------
>> 
>> 
>>> One could take the position that the library and require functions
>>were a mistake 
>>> to begin with and that all contributed packages should be accessed
>>using ::... or 
>>> one could recognize that these functions are an expected feature of R
>>at this 
>>> point and then it is not defensible to ban the proposed approach of
>>importing 
>>> names as Stefan wants to. I don't think it is fair to require this
>>higher level of 
>>> specificity just because it involves use of attach.
>>> 
>>> That said, another feature of R packages is the integrated help
>>system... 
>>> importing Julia functions wholesale may lead to problems with
>>consistency in 
>>> navigating the help files. IMO it may be justifiable to ban this
>>particular 
>>> syntactic convenience to maintain some separation in the minds of
>>users looking 
>>> for help on these new functions, since the syntactic and semantic
>>structure of 
>>> functions from another language may not align well with normal R
>>functions. But I 
>>> am not familiar with Julia or Stefan's package or the support it
>>brings in this 
>>> area... I just disagree with banning a "library" lookalike function
>>"just 
>>> because" it happens to involve attach.
>>> 
>>> On April 6, 2020 8:40:12 AM PDT, Duncan Murdoch
>><murdoch.duncan using gmail.com> 
>>> wrote:
>>>>On 06/04/2020 11:25 a.m., Stefan Lenz IMBI wrote:
>>>>> Yes, as I wrote earlier, I would like to imitate the behaviour of
>>>>loading an R package
>>>>> 
>>>>> juliaUsing("SomeJuliaPackage") # exports myJuliaFunction
>>>>> myJuliaFunction()
>>>>> 
>>>>> like R:
>>>>> 
>>>>> library("MyRPackage") # exports myRFunction
>>>>> myRFunction()
>>>>> 
>>>>> I could return an environment, such that the call becomes
>>>>> 
>>>>> attach(juliaUsing("SomeJuliaPackage"))
>>>>> myJuliaFunction()
>>>>
>>>>I wouldn't use it that way. I'd write it as
>>>>
>>>> sjp <- juliaUsing("SomeJuliaPackage")
>>>> sjp$myJuliaFunction()
>>>>
>>>>This is similar to the advice to use pkg::foo() rather than
>>>>library(pkg) 
>>>>followed by plain foo() in the code.
>>>>
>>>>Duncan Murdoch
>>>>
>>>>> 
>>>>> But calling juliaUsing(), as it is now, takes care that if a
>>package
>>>>is imported a second time,
>>>>> the first data base is removed via detach().
>>>>> This way, users do not have to worry about calling juliaUsing()
>>>>mutliple times in a script, same
>>>>> as R users don't have to worry about calling library() multiple
>>>>times.
>>>>> If you call the code with attach() multiple times and do not
>>detach,
>>>>you get your screen cluttered with
>>>>> warnings "xxx is masked by xxx".
>>>>> So I would say it would decrease user-friendliness to return an
>>>>environment.
>>>>> I also want to make explicit, that the call to attach
>>>>> occurs only once in my code, after creating the environment:
>>>>> 
>>>>> envName <- paste0("JuliaConnectoR:", absoluteModulePath)
>>>>> if (envName %in% search()) {
>>>>> detach(envName, character.only = TRUE)
>>>>> }
>>>>> attach(funenv, name = envName)
>>>>> 
>>>>> This code is only called by juliaImport() and juliaUsing(), which
>>>>aren't called by any other function of
>>>>> the package
>>>>> and are supposed to be called directly by the user.
>>>>> 
>>>>> Stefan
>>>>> 
>>>>> ----------------ursprüngliche Nachricht-----------------
>>>>> Von: Duncan Murdoch [murdoch.duncan using gmail.com]
>>>>> An: Dirk Eddelbuettel [edd using debian.org], Ben Bolker
>>>>[bbolker using gmail.com]
>>>>> Kopie: List r-package-devel [r-package-devel using r-project.org]
>>>>> Datum: Mon, 6 Apr 2020 11:00:09 -0400
>>>>> -------------------------------------------------
>>>>> 
>>>>> 
>>>>>> On 06/04/2020 10:49 a.m., Dirk Eddelbuettel wrote:
>>>>>>>
>>>>>>> On 6 April 2020 at 08:38, Ben Bolker wrote:
>>>>>>> | Just reply to the CRAN maintainers and explain this situation.
>>>>It¨s
>>>>>>> | slightly buried, but the e-mail you received does say:
>>>>>>> |
>>>>>>> | > If you are fairly certain the rejection is a false positive,
>>>>please reply-all to this
>>>>>>> | > message and explain.
>>>>>>>
>>>>>>> True, but this misses the "Letter of the law" versus the "Spirit
>>of
>>>>the law".
>>>>>>>
>>>>>>> It might be worth mentioning that use of attach() is seen, to
>>find
>>>>one poor
>>>>>>> analogy, pretty much like use of global variables these days.
>>"Just
>>>>because
>>>>>>> you could does not mean you should".
>>>>>>>
>>>>>>> See e.g. one of the first google hits for 'r do not use attach'
>>>>here:
>>>>>>>
>>>>https://stackoverflow.com/questions/10067680/why-is-it-not-advisable-to-use-attach-in-r-and-what-should-i-use-instead
>>>>>>
>>>>>> I don't have a strong opinion on this: the proposed use seems to
>>be
>>>>no
>>>>>> worse than library() or require(). Those are fine for users to
>>use,
>>>>but
>>>>>> are discouraged in a package. If the attach() never happens
>>without
>>>>an
>>>>>> explicit request from the user (and that's what it sounds like),
>>I'd
>>>>say
>>>>>> it's probably okay.
>>>>>>
>>>>>> However, there is an easy workaround: just return the environment
>>>>>> without attaching it. Then the user has the choice of attaching
>>it,
>>>>or
>>>>>> using it as a prefix when they call the functions in it. So it's
>>not
>>>>as
>>>>>> though this will destroy the utility of the package if Stefan
>>isn't
>>>>>> allowed to call attach().
>>>>>>
>>>>>> Duncan Murdoch
>>>>>>
>>>>>> ______________________________________________
>>>>>> R-package-devel using r-project.org mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>>>
>>>>> 
>>>>>
>>>>
>>>>______________________________________________
>>>>R-package-devel using r-project.org mailing list
>>>>https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>> 
> 


-- 

Stefan Lenz

Institut für Medizinische Biometrie und Statistik
Medizinische Fakultät / Universitätsklinikum Freiburg

Postadresse: Stefan-Meier-Str. 26, 79104 Freiburg

Tel.: 0761/203-6670
E-Mail: lenz using imbi.uni-freiburg.de

More information about the R-package-devel mailing list