devtools

repository·main·Indexed 25 days ago

https://github.com/r-lib/devtools

A collection of R functions designed to simplify and expedite R package development. It provides a unified interface for tasks including loading code with load_all(), generating documentation via document(), running tests with test(), building packages, and managing CRAN submissions. The library integrates several specialized packages such as testthat, roxygen2, pak, pkgbuild, pkgload, rcmdcheck, and usethis.

Tokens
1.5K
Snippets
2
Records
10
Agent score
81%

What's inside devtools

  1. Understand the devtools 'Conscious Uncoupling' architecture

    main

    While devtools provides a single interface for package development, it is composed of several specialized, smaller packages. For day-to-day development, it is recommended to use library(devtools) to load all tools at once.

    However, if you are building your own package or a deployed application, you should depend on the specific underlying packages directly rather than depending on devtools.

    Core underlying packages:

    • testthat: Writing and running tests (test())
    • roxygen2: Documentation (document())
    • pak: Installing packages (pak::pak())
    • pkgbuild: Building binary packages (build())
    • pkgload: Simulating package loading (load_all())
    • rcmdcheck: Running R CMD check (check())
    • revdepcheck: Running checks on reverse dependencies (revdep_check())
    • sessioninfo: R session info (session_info())
    • usethis: Automating package setup (use_test())
  2. Frequent development tasks with devtools

    main

    Most devtools functions accept a path as an argument (e.g., load_all("path/to/mypkg")). If no path is specified, the function looks in the current working directory, which is the recommended practice.

    Common tasks include:

    • load_all(): Simulates installing and reloading your package. It loads R code in R/, compiled shared objects in src/, and data files in data/. It makes all functions available, including un-exported internal ones.
    • document(): Updates generated documentation in man/, file collation, and the NAMESPACE file.
    • test(): Reloads your code using load_all() and then runs all testthat tests.
    • test_coverage(): Runs test coverage on your package using the covr package to identify untested code parts.
    # Example usage in a package directory
    load_all()
    document()
    test()
    test_coverage()
  3. Install devtools

    main

    You can install the stable version of devtools from CRAN or the development version from GitHub using pak.

    # Install devtools from CRAN
    install.packages("devtools")
    
    # Or the development version from GitHub:
    # install.packages("pak")
    pak::pak("r-lib/devtools")
  4. Troubleshoot vignette re-building errors

    main

    When re-building vignettes fails during a package check, common causes include:

    1. Missing Dependencies: An error like <error/rlib_error_package_not_found> often indicates that a package required by a function (e.g., remotes required by devtools::install_git()) is not installed in the environment.
    2. Environment Variables: Some packages (like those using pak) may require specific environment variables to be set during the check process. For example, if you see an error regarding get_user_cache_dir(), ensure the R_USER_CACHE_DIR environment variable is correctly configured.

    Example error for missing dependency:

    Error in `devtools::install_git()`:
    ! The package "remotes" is required.
  5. Troubleshoot Rd cross-reference warnings

    main

    If you receive a warning about missing links in Rd files, it means a cross-reference to a function or package is broken. This typically looks like:

    Missing link(s) in Rd file 'filename.Rd':
      ‘[package:namespace]{package::function}’

    Refer to the 'Writing R Extensions' manual section on 'Cross-references' to fix these links.

  6. Troubleshoot test and example failures

    main

    Failures in checking tests or checking examples can stem from several issues:

    1. Test Logic Failures: Standard testthat failures where expected values do not match actual values (e.g., Expected nrow(plan) to equal nrow(mat2)).
    2. Example Execution Errors: Errors occurring within the Examples section of a package documentation, often due to missing setup steps or environment mismatches.
    3. Subprocess Errors: Errors occurring within dependencies or subprocesses (like pak) that bubble up to the main test suite.
  7. Get more information about reverse dependency failures

    main
    If you encounter a reverse dependency failure during revdepcheck, you can retrieve additional cloud details for a specific package using the revdepcheck::cloud_details() function. This is useful for investigating why a package failed to install or check in the automated environment.
  8. Build and install R packages

    main

    Use these functions to manage package installation and building:

    • install(): Reinstalls the package, detaches the currently loaded version, and reloads the new version with library().
    • build(): Builds a package file (e.g., a binary version) from package sources.
    • update_packages(): Updates packages to their latest versions (works for CRAN and other installation sources).

    Specific installation functions:

    • install_github(): From GitHub
    • install_gitlab(): From GitLab
    • install_bitbucket(): From Bitbucket
    • install_url(): From an arbitrary URL
    • install_git(): From an arbitrary git repository
    • install_svn(): From an arbitrary SVN repository
    • install_local(): From a local file on disk
    • install_version(): From a specific version on CRAN
  9. Check and release packages

    main

    Functions for verifying package integrity and preparing for CRAN submission:

    • check(): Updates documentation, then builds and checks the package locally.
    • check_win_release(), check_win_devel(), and check_mac_release(): Checks a package using win-builder or macbuilder.
    • release() and submit_cran(): Handle the mechanics of CRAN submission, with or without (re)-running local checks.
  10. Get detailed reverse dependency check information

    main

    If you encounter issues with a package during reverse dependency checks, you can retrieve more detailed diagnostic information using the revdepcheck::cloud_details() function. This is useful for investigating why a package is marked as 'newly broken'.

    To get details for a specific package, pass the package name as the second argument to cloud_details().