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
>>>> already.
>>>
>>> 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
>> sucks".
>>
>> What if we added a flag to the package properties ("needs_R" or
similar),
>> 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
"foreign language=R"
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.
Allin