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 [jdnew...@dcn.davis.ca.us]
An: Stefan Lenz IMBI [l...@imbi.uni-freiburg.de],
r-package-devel@r-project.org, Duncan Murdoch [murdoch.dun...@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 <l...@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 [jdnew...@dcn.davis.ca.us]
>>An: r-package-devel@r-project.org, Duncan Murdoch
>>[murdoch.dun...@gmail.com], Stefan Lenz IMBI
>>[l...@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.dun...@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.dun...@gmail.com]
>>>>> An: Dirk Eddelbuettel [e...@debian.org], Ben Bolker
>>>>[bbol...@gmail.com]
>>>>> Kopie: List r-package-devel [r-package-devel@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@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
>>>
>
--
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: l...@imbi.uni-freiburg.de
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
