On Thu, 28 Sep 2017, Riccardo (Jack) Lucchetti wrote:
On Thu, 28 Sep 2017, Allin Cottrell wrote:
> On Thu, 28 Sep 2017, Riccardo (Jack) Lucchetti wrote:
>
>> 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.
Hm, that's right. Which leads us back to my previous idea that, if someone
writes a package which depends on R somehow, there's a flag in the package
metadata that should prevent installation on an R-less system. I don't think
that expecting the package writer to set the flag by hand is too much to ask.
Agreed. The set of hansl coders who'd be inclined to write
R-dependent packages is probably quite small, and its members quite
savvy. Asking them to set a flag (plus being clear about the
dependency in the help text) is not out of order.
Allin