Skip to content

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

10 messages · Andrew Simmons, Berry Boessenkool, Mark Miller +3 more

Original
Andrew Simmons
# 
I noticed in the Writing R Extensions manual, it says that within a
NAMESPACE file, "Only very simple conditional processing of if statements
is implemented.".
I tried it out myself by importing a Windows exclusive function:


if (.Platform$OS.type == "windows")
    importFrom(utils, getWindowsHandles)


It also says in the manual that a NAMESPACE file "is not processed as R
code", so I'm wondering if anyone knows exactly how if statements are
handled within a NAMESPACE file.
Duncan Murdoch
#
On 29/09/2021 2:13 p.m., Andrew Simmons wrote:
For a question like this, going to the source is really the only choice. 
  NAMESPACE is parsed when the package is installed, using the function 
parseNamespaceFile from the base package.

What that function does is to parse NAMESPACE as if it is R code, then 
go through the unevaluate expressions.  If it comes across one that is 
an "if", it evaluates it in the global environment.  But usually that's 
not *your* global environment, that's the global environment that is in 
place while the package is being installed.

If the condition is TRUE, it handles the clause that follows; if FALSE, 
it will look at the "else" clause.

So your

   if (.Platform$OS.type == "windows")

would be fine because .Platform is in the base package, so it's 
guaranteed to be available.  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
Berry Boessenkool
# 
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
Mark Miller
# 
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 at hotmail.com> wrote:

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Andrew Simmons
    

    

      
      #
    

  


  

      
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 at gmail.com>
wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Jeff Newmiller
    

    

      
      #
    

  


  

      
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.

        
On September 30, 2021 11:52:16 AM PDT, Andrew Simmons <akwsimmo at gmail.com> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 30/09/2021 5:21 p.m., Jeff Newmiller wrote:

            

      
      
      
    

        
Sorry, too much context missing.  What's unstable?

Duncan Murdoch

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      John Harrold
    

    

      
      #
    

  


  

      
I don't have cigwin installed but from the command window, the terminal
that Git installs, RGui, and RStudio they all return "windows" for the
.Platform$OS.type for me.

On Thu, Sep 30, 2021 at 2:38 PM Duncan Murdoch <murdoch.duncan at gmail.com>
wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      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 at gmail.com> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Andrew Simmons
    

    

      
      #
    

  


  

      
You are correct, it most definitely is a convoluted way to identify a path,
but this is one incredibly specific scenario. The case I'm talking about
only occurs when running a script in Rgui for Windows using Ctrl+R (or
pasting into the R Console) to run a piece of code. Scenarios such as
running from the Windows command-line / / Unix terminal / / using source,
sys.source, RStudio's debugSource, and testthat::source_file are handled in
a much different and less convoluted manner.
And in this case, the window handle relevant to the script has to exist,
otherwise you couldn't open the script in Rgui in the first place. I'm not
disagreeing that it's a horrible way to retrieve the path of the executing
script, but it's the only way if you're running from an open script in Rgui
for Windows.

On Thu, Sep 30, 2021 at 5:53 PM Jeff Newmiller <jdnewmil at dcn.davis.ca.us>
wrote: