[R-pkg-devel] Add SystemRequirements of imported package in description file?

[Dominik Leutnant]

Hi all,

should “SystemRequirements” of an imported package be listed in the description 
file of a package?

General scenario:
- Package X imports Package Y.
- Package Y lists “libzzz” as SystemRequirements.

Should Package X list the SystemRequirements “libzzz” as well? (question 
occurred @ https://github.com/dleutnant/influxdbr/issues/47)

Thank you and happy easter!
Dominik



Dr. Dominik Leutnant
Department of Civil Engineering
Institute for Infrastucture·Water·Resources·Environment (IWARU)
WG Urban Hydrology and Water Management

Muenster University of Applied Sciences
Corrensstr. 25
FRG-48149 Münster
Germany

Tel.:  +49 (0) 251/83-65274
Mail:  leutn...@fh-muenster.de
Web: https://www.fh-muenster.de/


[[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] Add SystemRequirements of imported package in description file?

[Thierry Onkelinx]

Dear Dominik,

IMHO you only need to list "first order" dependencies: things that your
package directly uses. Listing higher order dependencies would be redundant
as they are listed in the packages that have them as first order dependency.

Best regards,

ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be
Havenlaan 88 bus 73, 1000 Brussel
www.inbo.be

///
To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of data.
~ John Tukey
///




Op do 9 apr. 2020 om 09:52 schreef Dominik Leutnant :

> Hi all,
>
> should “SystemRequirements” of an imported package be listed in the
> description file of a package?
>
> General scenario:
> - Package X imports Package Y.
> - Package Y lists “libzzz” as SystemRequirements.
>
> Should Package X list the SystemRequirements “libzzz” as well? (question
> occurred @ https://github.com/dleutnant/influxdbr/issues/47)
>
> Thank you and happy easter!
> Dominik
>
>
>
> Dr. Dominik Leutnant
> Department of Civil Engineering
> Institute for Infrastucture·Water·Resources·Environment (IWARU)
> WG Urban Hydrology and Water Management
>
> Muenster University of Applied Sciences
> Corrensstr. 25
> FRG-48149 Münster
> Germany
>
> Tel.:  +49 (0) 251/83-65274
> Mail:  leutn...@fh-muenster.de
> Web: https://www.fh-muenster.de/
>
>
> [[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

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

[Stefan Lenz IMBI]

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  
> 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
>> 
>>> 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
time

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

[Joris Meys]

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  on behalf of 
Stefan Lenz IMBI 
Sent: Thursday, April 9, 2020 10:41 AM
To: Jeff Newmiller; r-package-devel@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 [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 
> 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 f

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

[Stefan Lenz IMBI]

Hi!
Thanks for pointing to the package "namespace". 
I experimented with it but I couldn't really figure out how it is supposed to 
work:

The following code leads to strange errors that I don't understand:

 > nse <- list2env(list(data="x", asdf = 2))
 > namespace::registerNamespace(name = "NewNamespace", env = nse)
 > NewNamespace::asdf
 Error in asNamespace(ns) : not a namespace

It would really be interesting if someone could comment on whether the 
namespace approach is feasible, how it is supposed to work, and whether/how it 
would be better than using attach.
Greetings!
Stefan

 
ursprüngliche Nachricht-
Von: Joris Meys [joris.m...@ugent.be]
An: Stefan Lenz IMBI [l...@imbi.uni-freiburg.de], Jeff Newmiller 
[jdnew...@dcn.davis.ca.us], r-package-devel@r-project.org, Duncan Murdoch 
[murdoch.dun...@gmail.com]
Datum: Thu, 9 Apr 2020 12:59:23 +
-
 
 
> 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  on behalf 
> of Stefan Lenz IMBI 
> Sent: Thursday, April 9, 2020 10:41 AM
> To: Jeff Newmiller; r-package-devel@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 [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 
>> 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]
>>>

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

[Joris Meys]

Hi Stefan,

you need the function makeNamespace() to create the environment as a namespace. 
Look at the examples in the help files, I found them rather instructive. I also 
hope someone else chimes in to shed some light on whether or not that approach 
would be acceptable. 


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: Stefan Lenz IMBI 
Sent: Thursday, April 9, 2020 5:30 PM
To: Joris Meys; Jeff Newmiller; r-package-devel@r-project.org; Duncan Murdoch
Subject: Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission 
JuliaConnectoR 0.5.0

Hi!
Thanks for pointing to the package "namespace".
I experimented with it but I couldn't really figure out how it is supposed to 
work:

The following code leads to strange errors that I don't understand:

 > nse <- list2env(list(data="x", asdf = 2))
 > namespace::registerNamespace(name = "NewNamespace", env = nse)
 > NewNamespace::asdf
 Error in asNamespace(ns) : not a namespace

It would really be interesting if someone could comment on whether the 
namespace approach is feasible, how it is supposed to work, and whether/how it 
would be better than using attach.
Greetings!
Stefan


ursprüngliche Nachricht-
Von: Joris Meys [joris.m...@ugent.be]
An: Stefan Lenz IMBI [l...@imbi.uni-freiburg.de], Jeff Newmiller 
[jdnew...@dcn.davis.ca.us], r-package-devel@r-project.org, Duncan Murdoch 
[murdoch.dun...@gmail.com]
Datum: Thu, 9 Apr 2020 12:59:23 +
-


> 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  on behalf
> of Stefan Lenz IMBI 
> Sent: Thursday, April 9, 2020 10:41 AM
> To: Jeff Newmiller; r-package-devel@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 [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

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

[Stefan Lenz IMBI]

When I execute the example, I also get a strange behaviour:

 library(namespace)
 ns <- makeNamespace("myNamespace")
 assign("test",7, env=ns)
 ls(env=ns) 

When I now want to invoke any help for a function, I get a warning message:

 > ?loadNamespace
 Warning message:
 In find.package(if (is.null(package)) loadedNamespaces() else package, :
 there is no package called ‘myNamespace’

Also sessionInfo doesn't work any more:

 > sessionInfo()
 Error in if (pkgpath == "") { : argument is of length zero

I don't think this is a good sign
Stefan

 
ursprüngliche Nachricht-
Von: Joris Meys [joris.m...@ugent.be]
An: Stefan Lenz IMBI [l...@imbi.uni-freiburg.de], r-package-devel@r-project.org
Datum: Thu, 9 Apr 2020 15:37:09 +
-
 
 
> Hi Stefan,
> 
> you need the function makeNamespace() to create the environment as a 
> namespace. 
> Look at the examples in the help files, I found them rather instructive. I 
> also 
> hope someone else chimes in to shed some light on whether or not that 
> approach 
> would be acceptable.
> 
> 
> 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: Stefan Lenz IMBI 
> Sent: Thursday, April 9, 2020 5:30 PM
> To: Joris Meys; Jeff Newmiller; r-package-devel@r-project.org; Duncan 
> Murdoch
> Subject: Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission 
> JuliaConnectoR 0.5.0
> 
> Hi!
> Thanks for pointing to the package "namespace".
> I experimented with it but I couldn't really figure out how it is supposed to 
> work:
> 
> The following code leads to strange errors that I don't understand:
> 
> > nse <- list2env(list(data="x", asdf = 2))
> > namespace::registerNamespace(name = "NewNamespace", env = nse)
> > NewNamespace::asdf
> Error in asNamespace(ns) : not a namespace
> 
> It would really be interesting if someone could comment on whether the 
> namespace 
> approach is feasible, how it is supposed to work, and whether/how it would be 
> better than using attach.
> Greetings!
> Stefan
> 
> 
> ursprüngliche Nachricht-
> Von: Joris Meys [joris.m...@ugent.be]
> An: Stefan Lenz IMBI [l...@imbi.uni-freiburg.de], Jeff Newmiller 
> [jdnew...@dcn.davis.ca.us], r-package-devel@r-project.org, Duncan 
> Murdoch [murdoch.dun...@gmail.com]
> Datum: Thu, 9 Apr 2020 12:59:23 +
> -
> 
> 
>> 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  on behalf
>> of Stefan Lenz IMBI 
>> Sent: Thursday, April 9, 2020 10:41 AM
>> To: Jeff Newmiller; r-package-devel@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

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

[Joris Meys]

You're right, that's enough to not dig any further. I remembered it from the 
earlier days of devtools, but they removed that dependency ages ago. I also 
believe now the namespace package predates the later changes to the namespace 
mechanism. Forget what I said, I should have spent a bit more time testing it 
myself first.

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: Stefan Lenz IMBI 
Sent: Thursday, April 9, 2020 6:09 PM
To: Joris Meys; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission 
JuliaConnectoR 0.5.0

When I execute the example, I also get a strange behaviour:

 library(namespace)
 ns <- makeNamespace("myNamespace")
 assign("test",7, env=ns)
 ls(env=ns)

When I now want to invoke any help for a function, I get a warning message:

 > ?loadNamespace
 Warning message:
 In find.package(if (is.null(package)) loadedNamespaces() else package, :
 there is no package called ‘myNamespace’

Also sessionInfo doesn't work any more:

 > sessionInfo()
 Error in if (pkgpath == "") { : argument is of length zero

I don't think this is a good sign
Stefan


ursprüngliche Nachricht-
Von: Joris Meys [joris.m...@ugent.be]
An: Stefan Lenz IMBI [l...@imbi.uni-freiburg.de], r-package-devel@r-project.org
Datum: Thu, 9 Apr 2020 15:37:09 +
-


> Hi Stefan,
>
> you need the function makeNamespace() to create the environment as a 
> namespace.
> Look at the examples in the help files, I found them rather instructive. I 
> also
> hope someone else chimes in to shed some light on whether or not that approach
> would be acceptable.
>
>
> 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: Stefan Lenz IMBI 
> Sent: Thursday, April 9, 2020 5:30 PM
> To: Joris Meys; Jeff Newmiller; r-package-devel@r-project.org; Duncan
> Murdoch
> Subject: Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission
> JuliaConnectoR 0.5.0
>
> Hi!
> Thanks for pointing to the package "namespace".
> I experimented with it but I couldn't really figure out how it is supposed to 
> work:
>
> The following code leads to strange errors that I don't understand:
>
> > nse <- list2env(list(data="x", asdf = 2))
> > namespace::registerNamespace(name = "NewNamespace", env = nse)
> > NewNamespace::asdf
> Error in asNamespace(ns) : not a namespace
>
> It would really be interesting if someone could comment on whether the 
> namespace
> approach is feasible, how it is supposed to work, and whether/how it would be
> better than using attach.
> Greetings!
> Stefan
>
>
> ursprüngliche Nachricht-
> Von: Joris Meys [joris.m...@ugent.be]
> An: Stefan Lenz IMBI [l...@imbi.uni-freiburg.de], Jeff Newmiller
> [jdnew...@dcn.davis.ca.us], r-package-devel@r-project.org, Duncan
> Murdoch [murdoch.dun...@gmail.com]
> Datum: Thu, 9 Apr 2020 12:59:23 +
> -
>
>
>> 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  on behalf
>> of Stefan Lenz IMBI 
>> Sent: Thursday, April 9, 2020 10:41 AM
>> To: Jeff Ne

[R-pkg-devel] manual inspection of new packages

[John Lawson]

I submitted the Package AQLSchemes on Dec 9, 2019. I corrected the errors
noted in the manual inspection and resubmitted it on Jan 9. I got the
message that it passed the automatic checks and was awaiting manual
inspection. I have not heard anything since.  Do I need to resubmitt the
package? Or how can I find out if this package is still in the queue for
manual inspection?

Thank you
John Lawson

[[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] manual inspection of new packages

[Ben Bolker]

  foghorn::cran_incoming() will let you inspect the package queue.

  (most likely if the package has been sitting this long it's not ever 
going to move farther through the queue and you should resubmit.  An 
e-mail to the CRAN maintainers after you check the status would probably 
be appropriate.)



On 4/9/20 3:28 PM, John Lawson wrote:

I submitted the Package AQLSchemes on Dec 9, 2019. I corrected the errors
noted in the manual inspection and resubmitted it on Jan 9. I got the
message that it passed the automatic checks and was awaiting manual
inspection. I have not heard anything since.  Do I need to resubmitt the
package? Or how can I find out if this package is still in the queue for
manual inspection?

Thank you
John Lawson

[[alternative HTML version deleted]]

__
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] manual inspection of new packages

[Duncan Murdoch]

On 09/04/2020 3:28 p.m., John Lawson wrote:

I submitted the Package AQLSchemes on Dec 9, 2019. I corrected the errors
noted in the manual inspection and resubmitted it on Jan 9. I got the
message that it passed the automatic checks and was awaiting manual
inspection. I have not heard anything since.  Do I need to resubmitt the
package? Or how can I find out if this package is still in the queue for
manual inspection?



As the CRAN policy document says under Submission, you can see the queue 
by looking at ftp://cran.r-project.org/incoming/.  The foghorn package 
makes this really easy:  you run foghorn::cran_incoming("AQLSchemes") to 
see where your package is sitting.  It doesn't appear to be there at all.


Next time, I'd follow up if you go a week without hearing a reply; 
waiting 3 months seems a bit long.


Duncan Murdoch

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

Re: [R-pkg-devel] Add SystemRequirements of imported package in description file?

[Jeff Newmiller]

AFAIK, no, though if the upstream package cannot (or won't) be implemented 
without that system requirement and it really is a requirement for this package 
then you might want to indicate "libzzz via Package X" just to be clear for 
users. If it isn't a requirement for most of your functionality then you may 
want to use Suggests to alleviate the problem.

On April 9, 2020 12:51:56 AM PDT, Dominik Leutnant  
wrote:
>Hi all,
>
>should “SystemRequirements” of an imported package be listed in the
>description file of a package?
>
>General scenario:
>- Package X imports Package Y.
>- Package Y lists “libzzz” as SystemRequirements.
>
>Should Package X list the SystemRequirements “libzzz” as well?
>(question occurred @ https://github.com/dleutnant/influxdbr/issues/47)
>
>Thank you and happy easter!
>Dominik
>
>
>
>Dr. Dominik Leutnant
>Department of Civil Engineering
>Institute for Infrastucture·Water·Resources·Environment (IWARU)
>WG Urban Hydrology and Water Management
>
>Muenster University of Applied Sciences
>Corrensstr. 25
>FRG-48149 Münster
>Germany
>
>Tel.:  +49 (0) 251/83-65274
>Mail:  leutn...@fh-muenster.de
>Web: https://www.fh-muenster.de/
>
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
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

Re: [R-pkg-devel] manual inspection of new packages

[John Lawson]

Ok, thanks.

On Thu, Apr 9, 2020 at 1:46 PM Duncan Murdoch 
wrote:

> On 09/04/2020 3:28 p.m., John Lawson wrote:
> > I submitted the Package AQLSchemes on Dec 9, 2019. I corrected the errors
> > noted in the manual inspection and resubmitted it on Jan 9. I got the
> > message that it passed the automatic checks and was awaiting manual
> > inspection. I have not heard anything since.  Do I need to resubmitt the
> > package? Or how can I find out if this package is still in the queue for
> > manual inspection?
> >
>
> As the CRAN policy document says under Submission, you can see the queue
> by looking at ftp://cran.r-project.org/incoming/.  The foghorn package
> makes this really easy:  you run foghorn::cran_incoming("AQLSchemes") to
> see where your package is sitting.  It doesn't appear to be there at all.
>
> Next time, I'd follow up if you go a week without hearing a reply;
> waiting 3 months seems a bit long.
>
> Duncan Murdoch
>

[[alternative HTML version deleted]]

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