[R-pkg-devel] if statements in NAMESPACE file

[Jeff Newmiller]

Expecting a window handle relevant to the script to exist for the purpose of identifying a path seem to be orthogonal problems to me. But Andrew has indicated offlist that he has alternate code for other cases only uses this technique when appropriate.

I still feel this is too convoluted as a way to identify a path, but if he covers all cases then my opinion is just an opinion.

On September 30, 2021 2:34:48 PM PDT, Duncan Murdoch <murdoch.duncan using gmail.com> wrote:
>On 30/09/2021 5:21 p.m., Jeff Newmiller wrote:
>> What if you are on Windows but running R at the command prompt, or via cygwin, or in the console window of RStudio?
>> 
>> This seems unstable to me.
>
>Sorry, too much context missing.  What's unstable?
>
>Duncan Murdoch
>
>> 
>> On September 30, 2021 11:52:16 AM PDT, Andrew Simmons <akwsimmo using gmail.com> wrote:
>>> Hello,
>>>
>>>
>>> I'm updating my package 'this.path' which is supposed to retrieve the
>>> absolute path of the executing script when called. It's similar to 'here',
>>> except that 'here' constructs paths relative to a project directory,
>>> whereas 'this.path' constructs paths relative to script directories. I was
>>> updating the section where I retrieve the executing script's path while
>>> running from a script open in Rgui for Windows, and I needed
>>> utils::getWindowsHandles to do such a thing. But utils::getWindowsHandles
>>> is a Windows only function, I
>>> would imagine that 'utils' contains a similar line of code as above:
>>>
>>>
>>> if (.Platform$OS.type == "windows")
>>>     getWindowsHandles <- function() ...
>>>
>>>
>>> and then in the NAMESPACE:
>>>
>>>
>>> if (.Platform$OS.type == "windows")
>>>     export(getWindowsHandles)
>>>
>>>
>>> so I'd like to change my code to getWindowsHandles and import
>>> getWindowsHandles from utils, but I can only do that on Windows, and so the
>>> conditional importing should work for me. At no point does my function
>>> mis-behave because of a attempting to use a function that isn't exported on
>>> that platform, because within the function it only uses getWindowsHandles
>>> if the OS is Windows.
>>>
>>>
>>> On Thu, Sep 30, 2021 at 11:01 AM Mark Miller <mark.roman.miller using gmail.com>
>>> wrote:
>>>
>>>> Returning to the original question, if it's helpful: I'd like to know what
>>>> constraints led to considering an export only available on Windows, and see
>>>> if we can suggest some other designs. It'd be good to keep the user's
>>>> mental model abstracted from the platform they're working on. There are
>>>> often unavoidable differences due to platform, but usually they're handled
>>>> with warnings and errors rather than selective exports.
>>>>
>>>> On Thu, Sep 30, 2021 at 3:40 AM Berry Boessenkool <
>>>> berryboessenkool using hotmail.com> wrote:
>>>>
>>>>>
>>>>> One of the very best fortunes nominations!
>>>>>
>>>>> [...]
>>>>>
>>>>>    I suspect something like
>>>>>
>>>>>     if (stats::runif(1) > 0.5) export(someFunction)
>>>>>
>>>>> would work too, for a particularly frustrating experience for your
>>>>> users.  It would mean half the installs export the function, and half
>>>>> don't.
>>>>>
>>>>> Duncan Murdoch
>>>>>
>>>>>
>>>>>          [[alternative HTML version deleted]]
>>>>>
>>>>> ______________________________________________
>>>>> R-package-devel using r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>>
>>>>
>>>>          [[alternative HTML version deleted]]
>>>>
>>>> ______________________________________________
>>>> R-package-devel using r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>
>>>
>>> 	[[alternative HTML version deleted]]
>>>
>>> ______________________________________________
>>> R-package-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
>

-- 
Sent from my phone. Please excuse my brevity.