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

Joris Meys Jor|@@Mey@ @end|ng |rom UGent@be
Thu Apr 9 14:59:23 CEST 2020 

Hi Stefan,

first of all, thank you for taking the time and effort to link Julia and R. That said, I would strongly encourage you to go for a reticulate-like approach. There's a good reason for that. Once you start mixing languages, you really want to have some indication what code is ran in what language. Especially since I can imagine at one point there'll be a Julia function masking an R function of the same name, and that is going to cause a world of hurt and confusion. 

If you don't like environments, you can try to use namespace functionality. There's the "namespace" package that allows you to create one, and some internal namespace functions are visible (eg namespaceExport() from base). That's going to be the closest to mimicking R packages, but it's beyond my knowledge to know how feasible this approach actually is. I hope someone else chimes in, especially if this is dangerous for other reasons I overlooked.

Kind regards
Joris

Joris Meys
Statistician
T +32 9 264 61 79

Department Data Analysis and Mathematical Modelling

Campus Coupure, Block A 1st floor 110.050, Coupure links 653, B-9000 Ghent, Belgium
T administration office +32 9 264 59 32

www.ugent.be

e-maildisclaimer


________________________________________
From: R-package-devel <r-package-devel-bounces using r-project.org> on behalf of Stefan Lenz IMBI <lenz using imbi.uni-freiburg.de>
Sent: Thursday, April 9, 2020 10:41 AM
To: Jeff Newmiller; r-package-devel using r-project.org; Duncan Murdoch
Subject: Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0

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

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

More information about the R-package-devel mailing list