Skip to content

[Wishlist] a 'PackageDevelopment' Task View

11 messages · Luca Braglia, Duncan Murdoch, Christophe Dutang +2 more

Original
Luca Braglia
# 
Hello everybody,

as a young/unexperienced R package developer (only a few, mainly
for personal use) i was thinking it could be very useful having a
"meta" task view for all package-development related
packages and/or function.

Something like ...

Creation
- utils::package.skeleton, pkgKitten, Rcpp::Rcpp.package.skeleton

Foreign languages interfaces:
- Rcpp

Documentation
- roxygen2

Profiling:
- utils::Rprof
- profr
- proftools

Unit test
- RUnit
- testthat

Spell checking
- tools::aspell_package_* functions

"Misc":
- devtools

and so on.

These are only the ones i (use or know) & (remember), but for
sure there is already a lot of useful code in this area and
having a summary (by more experienced developers) of which good
tools are available would be *very* useful, IMHO.

How about it?

Thanks, Luca
Duncan Murdoch
#
On 25/07/2014 8:05 AM, Luca Braglia wrote:
Sounds like a good idea.  You should do it.

Download the "ctv" package, and read the vignette for instructions.

Duncan Murdoch
1 day later
Luca Braglia
# 
2014-07-25 14:29 GMT+02:00 Duncan Murdoch <murdoch.duncan at gmail.com>:
Fine, I've set up a github repo here

https://github.com/lbraglia/PackageDevelopmentTaskView

and a first thread about task view structure here

https://github.com/lbraglia/PackageDevelopmentTaskView/issues/1

Contribution (via e-mail or github) are, of course, really welcome.

Cheers, Luca
Christophe Dutang
# 
Hi Luca,

Let me suggest to follow the table of contents of http://cran.r-project.org/doc/manuals/r-release/R-exts.html

For example, you could use the following TOC:

1 - Creating R pkg
2 - Writing documentation and vignettes
3 - Profiling code
4 - Debugging, spell checking
5 - Foreign languages interfaces
6 - GUI and other frond-ends 
7 - Unit testing
8 - Benchmarking
9 - Automation


Maybe 7 and 8 could be merged?

Regards, Christophe
?
Christophe Dutang
LMM, UdM, Le Mans, France
web: http://dutangc.free.fr

Le 26 juil. 2014 ? 17:04, Luca Braglia <lbraglia at gmail.com> a ?crit :
Luca Braglia
#
On 27/07/14 - 09:33, Christophe Dutang wrote:
Thanks Christophe for the feedback

I'm starting to think I'd like to keep the "Source Code" section
separated from the "Documentation" section ...  eg ideally the
macro topics could be in this order

1 - Creation
2 - Source Code
3 - Documentation
4 - Tools and services (was "Automation")

Furthermore IMHO a granular sub-topic structure is a plus (eg
few packages for a distinct/well-focused task is no problem,
maybe a resource ... )

An updated temp TOC (integrating your ideas, and some new
packages listed) could be

==============================================================

1 - Creation


  o Creating R packages - utils::package.skeleton, pkgKitten,
    Rcpp::Rcpp.package.skeleton 


2 - Source code


  o Foreign languages interfaces - base R support for that,
    inline, Rcpp , Rcpp11, rJava 

  o Debugging - base::debug utils::recover and friends

  o Code analysis - codetools

  o Profiling - utils::Rprof, aprof, profr, proftools 

  o Benchmarking - base::system.time, microbenchmarking, rbenchmark 

  o Unit testing - RUnit, svUnit, testthat 


3 - Documentation


  o Writing Package Documentation (functions, data sets, classes
    and methods, packages) - roxygen2

  o Writing Vignettes - Sweave, knitr

  o Spell checking - tools::aspell_package_* functions
   
 
4 - Tools and services


  o Editors (supporting package development)
  
  o IDEs (supporting package development)

  o Makefiles

  o Revision control (most common in the R community): 
    subversion, git

  o Hosting services (most common in the R community): 
    r-forge, github


==============================================================


I have a few doubts if "8.Linking GUIs and other front-ends to R"
from R-exts could be strictly in topic with _R_package_
development (eg looking at the list above) but not much
experience in that area and jm2c.

And I have to integrate these Gabor's suggestions yet :

1) List the software mentioned here or provide links:
   http://en.wikibooks.org/wiki/R_Programming/Settings#Integrated_development_environment
   http://en.wikipedia.org/wiki/Comparison_of_open-source_software_hosting_facilities
   http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
   http://en.wikipedia.org/wiki/Continuous_integration#Software

2) Go through the R Extensions manual and add all tools listed.

3) Use of Rcpp/Rcpp11 implies the use of C++ tools too and use of
   rjava implies java tools.




Further ideas/comments/proposals are welcome.


Cheers, Luca
Spencer Graves
#
On 7/27/2014 7:46 AM, Luca Braglia wrote:
I've heard claims that people who write documentation with unit 
tests first tend to get better code faster than people who write the 
code first and documentation (and maybe examples and unit tests) later.  
I've heard there is research behind this.  However, I'm not sure where 
to find it.  Others may be able to suggest publications that support or 
refute this claim.


       In any event, I tend to create (a) documentation first, including 
(b) unit tests in the examples section, before (c) writing code.  When I 
started writing R packages following this model, I felt my software 
development productivity increased by a factor of 5 or so.  That may 
sound crazy, but I had written code for decades and struggled 
continually with bugs introduced months or maybe years earlier.  "R CMD 
check" dramatically shortened the debug time to produce "trustworthy 
code" (John Chambers' "prime directive").  As a bonus, I got better 
software with documentation making it much easier to share with 
potential users -- in less time with less effort, heartache, blood, 
sweat and tears, etc.  I have not come to using roxygen2, though I've 
been enormously impressed with other things Hadley Wickham has done;  
fortune(298).


       This perspective is reflected in the Wikipedia article on 
"Package development process" and the comparison table of "Selected 
repositories" in the Wikipedia article on "Software repository".  I 
believe that both these articles could be improved by people with 
broader experience and deeper understanding of these issues than I have.


       Spencer Graves

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Luca Braglia
    

    

      
      #
    

  


  

      
On 27/07/14 -  08:42, Spencer Graves wrote:

            

      
      
      
    

        
Hi Spencer,

I'm trying that way of developing too (test before code), but
the numbering in my previous mail are not meant to be suggestion
for development process/flow steps (apologies for that, it was
only a way to alternate lists (numbers for sections, bullets for
tasks), no numbering is really going to be included in the task
view).

The proposed TOC was compiled in a way that (to me) eases finding which
packages are available, given what are you working on (source code
or documentation) and the specific task you need to accomplish.

Best,
  Luca

  
  


  


      

    

    

      
      

        


  

        

      Spencer Graves
    

    

      
      #
    

  


  

      
On 7/27/2014 9:23 AM, Luca Braglia wrote:

            

      
      
      
    

        
Of  course:  You need to write to match how your target audience 
would most likely want to approach the subject.


       Regarding "finding which packages are available", I didn't see 
the sos package on the list:  The "findFn" function searches the help 
pages of contributed packages and returns the results sorted so the 
package with the most matches and total score appear first. 
"writeFindFn2xls" produces an Excel workbook with a package summary 
followed by the list of individual pages.  For me, it's the fastest 
literature search I know for anything statistical.  Whatever I find 
there has documentation and working code that I can trace line by line 
if I don't understand the documentation.  I find things faster, and I 
learn faster as a result.  [Disclaimer:  I'm the lead author of sos.  If 
anyone knows anything better, I'd like to know.]


       Spencer

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Luca Braglia
    

    

      
      #
    

  


  

      
On 27/07/14 -  10:07, Spencer Graves wrote:

            

      
      
      
    

        
Many packages are still missing (eg devtools) because in these
first steps i'm trying to focus mainly on the Task View TOC/structure
(and in the case, devtools has to be "splitted" across tasks, TODO)

BTW sos is a great package, +1 for the disclaimer, but IMHO
doesn't fit R package development strictly

jm2c
  Luca

  
  


  


      

    

    

      
      

        


  

        

      Darren Norris
    

    

      
      #
    

  


  

      
Hi Luca,
Based on previous comments seems like
1) there should be a "multi-functional"/"general" category to cover packages
like devtools
2) I think finding existing function code ( e.g in cran packages / github )
is necessary and saves many hours in package development (no one wants to
develop a package and then discover they have just reinvented the wheel). So
including packages like sos seems justified and helpful.
Best,
Darren




--
View this message in context: http://r.789695.n4.nabble.com/Wishlist-a-PackageDevelopment-Task-View-tp4694537p4694625.html
Sent from the R devel mailing list archive at Nabble.com.

  
  


  


      

    

    
2 days later

    

      
      

        


  

        

      Luca Braglia
    

    

      
      #
    

  


  

      
On 27/07/14 -  13:19, Darren Norris wrote:

            

      
      
      
    

        
Thanks Darren and John,

considering both the programmer and the user point of view, being
a bit less strict about inclusion criteria in this case (search)
may be definitely helpful.

Best, 
 Luca