Skip to content

Porting "unmaintained" packages to post R 2.10.0 era

9 messages · Brian Ripley, Ben Rhelp, S Ellison +1 more

Ben Rhelp
# 
Hi all,

I am trying to re-compile some "unmaintained" (it seems) packages, namely rSoNIA 
and dynamicnetwork from:
http://csde.washington.edu/~skyebend/rsonia/rsoniaDemo/ 
These packages predates R 2.10.0 so they need to be recompile.

After split the single big file in /man in each packages into a file  for each 
function + some minor fix,  I successfully manage to recompile and load the 
packages

C:\BenSave\R\BuildRPackage>R CMD build --binary dynamicnetwork
--binary is deprecated
* checking for file 'dynamicnetwork/DESCRIPTION' ... OK
* preparing 'dynamicnetwork':
* checking DESCRIPTION meta-information ... OK
* checking whether 'INDEX' is up-to-date ... OK
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building binary distribution
* installing *source* package 'dynamicnetwork' ...
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded
     Classes for Relational Data
Version      1.6 created on      January 28, 2011.
copyright (c) 2005, Carter T. Butts, University of California-Irvine
                    Mark S. Handcock, University of Washington
                    David R. Hunter, Penn State University
                    Martina Morris, University of Washington
For citation information, type citation("network").
Type help("network-package") to get started.
* MD5 sums
packaged installation of 'dynamicnetwork' as dynamicnetwork_0.0-4.zip

* DONE (dynamicnetwork)

I then tried to run the main example, but it seems no function has been built 
(The help for these function is working for some reason).
Error: could not find function "as.dynamic"
Error: could not find function "launchSonia" 



Is there a HOWTO/porting guide for packages pre R 2.10.0 to post R 2.10.0?

I have tried googling for it but I must be looking at the wrong place.

What about "--binary is deprecated"? What is the correct way now?

Thanks in advance,

Ben
Uwe Ligges
#
On 16.06.2011 14:46, Ben Rhelp wrote:
Actually the main change was the help system for R-2.10.0. The structure 
of R code did not change at all.
See the manual. It tells you

R CMD INSTALL --build

will generate a binary package.

Best,
Uwe Ligges
Brian Ripley
#
On Thu, 16 Jun 2011, Mr Rhelp wrote:

            

      
      
      
    

        
Well, re-installed.

            

      
      
      
    

        
Sounds like you are doing this on Windows (please do tell us!) and 
trying to start with a Windows binary package.

            

      
      
      
    

        
Is that supposed to be R code?  R code lines don't end in semicolons.

            

      
      
      
    

        
You don't need one.  You start with the package sources, and install 
those.  If you don't have the sources, you ask the author for the 
sources.  But on the page you mention, I see

'unix/macs use the  *.tar.gz version'

by which they mean 'the source package'.

(Note that for GPLed packages such as this one, the sources must be 
made available.)

There are some errors in the format of the Rd files, but both packages 
install in R 2.13.0.  However, you are supposed to get Java components 
from a site which no longer exists, so I think you are going to need 
to ask the author for help.

One advantage of recent R is that to install packages like these from 
the sources you just need R, so there is no reason to distribute 
Windows binary packages (for such packages, with no C/C++/Fortran 
code).

            

      
      
      
    

        
R CMD INSTALL --build is preferred (and always has been on Windows).

But why are you trying to build a binary package before you even have 
it working?  Binary packages are really only useful for 
redistribution.

            

      
      
      
    

        
Surname 'Rhelp'

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Ben Rhelp
    

    

      
      #
    

  


  

      
----- Original Message ----

            

      
      
      
    

        
[...]

            

      
      
      
    

        
Hi Uwe,

Thanks a lot for this. I hope Google will rank your reply because it seems I am 
not the only one to make this mistake:

http://www.biostat.wisc.edu/~kbroman/Rintro/Rwinpack.html
http://robjhyndman.com/researchtips/building-r-packages-for-windows/
http://stevemosher.wordpress.com/step-10-build/

Cheers,

Ben

  
  


  


      

    

    

      
      

        


  

        

      Ben Rhelp
    

    

      
      #
    

  


  

      
Hi Prof Brian,

Thank you for your email and for writing MASS. This book is brilliant.


----- Original Message ----

            

      
      
      
    

        
[...]

            

      
      
      
    

        
Yes, sorry about that:

            

      
      
      
    

        
_                            
platform       x86_64-pc-mingw32            
arch           x86_64                       
os             mingw32                      
system         x86_64, mingw32              
status                                      
major          2                            
minor          13.0                         
year           2011                         
month          04                           
day            13                           
svn rev        55427                        
language       R                            
version.string R version 2.13.0 (2011-04-13)

[...]

            

      
      
      
    

        
Ok, my thinking was completely wrong. Your response help me to get things 
working. I have updated the packages to work with the latest version of the 
third party software (SoNIA) and I have contacted the original author with the 
aim to distribute some updated versions of the packages.
[...]

Thanks a lot again for your help.

Best regards,

Ben

  
  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
On 17.06.2011 12:04, Ben Rhelp wrote:

            

      
      
      
    

        
We know, and we always ask people to read the recent official manuals 
where this is mentioned rather than any outdated material.

Best,
Uwe Ligges

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      S Ellison
    

    

      
      #
    

  


  

          

      
      
      
    

        
...

            

      
      
      
    

        
I appreciate that one is expected to read the manuals, but having re-read the current docs I can only say that this information remains very well buried.

Section 1.3 of 'Checking and building packages'  in the present versions of 'Writing R extensions' starts with the clear statement "Using R CMD build, the R package builder, one can build R packages from their sources (for example, for subsequent release). "
This tells every package builder that R CMD BUILD is the appropriate route. There is no qualifying statement here such as 'For .tar.gz source packages... ' or 'except for zipped binaries which should now be built using R CMD INSTALL (see below).' And the entire section but for one line describes the use of R CMD build.

The one line in that manual that indicates that R CMD INSTALL is preferred simply states that "R CMD build can also build pre-compiled version of packages for binary distributions, but it is now deprecated in favour of R CMD INSTALL --build.". But here, no information is given on what the side effects are. For example, it would be reasonable to assume that INSTALL would install the package on one's own system, and if one does not intend that it is not at all clear what one should do instead. To find the side effects, one has to delve into Installation and Administration.

But while R Installation and administration mentions the INSTALL --build option, it is under the section "Checking installed source packages" and not under 'Installing..." or "Building...". Why would a package developer look there at all? They aren't checking an installed package yet. And in that section, it is clear that R CMD INSTALL --build is intended to _install check and package for distribution_ a package. A prudent package developer should surely not want to do all that in one go; they will want to check the package using check, build without affecting their current system once the check passes and then, if the builds are also successful, check - perhaps by installing from the console - that the binary and tar.gz install properly on a system that does not already include the package. That careful stepwise process is apparently not supported in the documentation under 'checking installed packages' so it's easy to see why a developer would not see this section as relevant even if they had thought to look under a section that seems irrelevant to package building.

So while I have every sympathy with R Core being frustrated that users don;t read manuals, I do rather think some clearer pointers could be given as to where in the manual to look and what to do if one does NOT want to install an untested package one one's own live system every time a distribution build is desired. Perhaps this has been sorted in the devel tree for 2.14, though?

S Ellison

            

      
      
      
    

        

      
      
    

        
This email and any attachments are confidential. Any use...{{dropped:8}}

  
  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
On 17.06.2011 14:39, Stephen Ellison wrote:

            

      
      
      
    

        
evant even if they had thought to look under a section that seems irrelevant to package building.

            

      
      
      
    

        
You can install to any library, even a temporary one that does not need 
to be in .libPaths() of your regular R installation. So you won't do any 
harm to your sytsem.

Why do you want to build a binary before checking? You only need a 
binary in order to distribute it, and I doubt you want to do that before 
you checked the package.

Best,
Uwe

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      S Ellison
    

    

      
      #
    

  


  

          

      
      
      
    

        
The principal point I was making is that "the manuals" are not very informative on the actual build step for a zipped binary and I can see why many find it hard to find the guidance they need. If there is a recommended practice - for example, what you've just said - why not include it in the manual intended to help package developers?

            

      
      
      
    

        
I don't want to build a binary before checking, and I didn't suggest that. I just wasn't talking about checking, which is well documented. I was talking about building zips, which isn't.

Steve E*******************************************************************
This email and any attachments are confidential. Any use...{{dropped:8}}