Working together with other packages

Overview

Working with other packages can mean:

• importing functionality from installed packages

• adding code, modifications to existing packages which are not yours

• including code from other packages into your own

Technical, legal, social, philosophical implications

General advice:

• Don’t worry too much (DWTM)
• Rapid prototyping, iterative improvement
• “Quality of life, quality of research (code)”

Depends, Imports, Suggests, Enhances: use one

Your package uses another installed package to do something:

• Your package: mypkg
• Other package: otherpkg

Depends:

• otherpkg necessary for installing mypkg
• After library(mypkg), otherpkg will be in the search path for the user
• Use case: mypkg really only makes sense in the context of otherpkg, e.g. latticeExtra and lattice
• Recommend: use rarely

Imports:

• otherpkg necessary for installing mypkg
• Functions etc. in otherpkg will be used internally by mypkg
• Details can be controlled in NAMESPACE
• Recommend: use this for necessary packages

Suggests:

• otherpkg NOT necessary for installing mypkg
• For packages only used in examples, vignettes, tests
• Typical use case: example data from another package

Enhances:

• otherpkg NOT necessary for installing mypkg
• When mypkg adds functionality to otherpkg
• Use case: mypkg has extra methods for classes defined in otherpkg

Reference: Writing R Extensions, Section 1.1.3

NAMESPACE specification

Reference: Writing R Extensions, Section 1.5

Exports

• Only exported functions are visible after library(mypkg) or via mypkg::
• Unexported functions are available as mypkg:::

• Suggestion:

  • start with default (export all, exportPattern("^[^\\.]")),
  • add @export-tags before release
  • don’t export hacks, functions you don’t document

Imports

• import(otherpkg) in NAMESPACE corresponds to library(otherpkg) in linear code
• Qualified names otherpkg:: will work without import/importFrom

• Suggestion:

  • @ìmport important packages at start (replace library)
  • use qualified names during development
  • switch to @import when you get tired of otherpkg::
  • before release, check whether to replace @import with @importFrom
  • use qualified names when in doubt

Contributing to other packages

• Report issues: informatively, politely (minimal replicable example)

• Add fixes via forking:

  • establish a private copy of a package (dead easy on Github)
  • make modifications
  • offer modifications to package owner (pull request)

  • Alt.: if the licence allows, go rogue with your own (forked) version

    • Nuclear option
    • Give credit
    • Change names, trademarks

• Play nice: e.g. ggplot2 code of conduct

Ressources:

• Forking on Wikepedia
• Legal aspects of forking on Github

Using material from other packages in your own

• Legal under open source licence under certain conditions

  • E.g.: “viral” property of GPL

• For legal & ethical reasons: give credit

We have to talk about licenses

Software licensing matters in research, same as data protection & citation rules.

Licensing R: not a legal document, but

• overview of current practice
• overview of open source (vs proprietary) licenses

Do I have to share?

• No.

• But you should think about it:

  • private vs public package: who to share with?
  • open vs proprietary licence
  • open access and open source

Have fun