On Thu, 28 Sep 2017, Riccardo (Jack) Lucchetti wrote:
On Thu, 28 Sep 2017, Sven Schreiber wrote:
> Am 28.09.2017 um 17:42 schrieb Riccardo (Jack) Lucchetti:
>> On Wed, 27 Sep 2017, Allin Cottrell wrote:
>>>> reconsider the policy that gretl function packages must not depend on R.
>>>> R has become so widespread, and also we have in gretl the very nice
>>>> possibility to define and call your own R functions directly (see
>>>> section 38.7 of the user guide), that it almost seems silly not to
>>>> leverage all the potential. Even Eviews has been doing it for a while
>>> I agree; I'd be OK with gretl packages that depend on R -- provided that
>>> what they do really requires R, it's not something that can be done
>>> without too much difficulty using native gretl commands or functions.
>> Ok, I hear what you say.
>> However, I'm not too keen on the idea that someone downloads a package,
>> watches it fail because R is not installed and concludes that "gretl
>> What if we added a flag to the package properties ("needs_R" or
>> and then we forbid installation of the package if R is not on the system,
>> with an appropriately prominent error message?
>> That would be rather easy to do, and prevent misunderstandings.
> Yes, either that, or we require the authors of such packages to have their
> packages check for R (if that's currently possible I'm not sure) and print
> out a corresponding message if it's missing. Package moderators would have
> to verify that.
Actually, the flag could be set automatically during the packaging process if
there's at least one instance of the line
in any of the functions. No manual checking by anybody.
I'd have to check to make sure, but I don't think that's quite
right: in principle an R-dependent package could sidestep "foreign"
by using R functions directly. That requires Rlib access (so far as
I remember, haven't tried this in a while), which would make a
package more restrictive in its set of potential users -- we build
in Rlib support in our Windows and Mac packages, but it's not
necessarily present on Linux. On the other hand using Rlib is more
efficient than running the R executable so we wouldn't necessarily
want to ban that in packages.