Source Type Details#

The CRAN Source#

A primary use case for Package Manager is making packages in public repositories, like CRAN, available to its users. Administrators can elect to make all of CRAN available, or to make only curated subsets of CRAN available.

Server log messages related to this component can be shown by enabling the sync region. More information about activating log regions is in the configuration appendix Debug section.

Bioconductor Sources#

Similar to CRAN, Package Manager makes packages from Bioconductor available to its users. The Bioconductor repository type includes one or more Bioconductor sources: one per Bioconductor version. Each of these CRAN-compatible sources are made up of component sources, such as the data, annotations, and other parts of Bioconductor. They are combined into the version meta-sources for easy access. There are two ways to work with Bioconductor packages:

• Using standard R commands to install packages. You'll avoid the Bioconductor repository type for this, and use Bioconductor source types instead.
• Using the BiocManager package. You'll use the Bioconductor repository type for this.

With either approach, administrators can make all of Bioconductor available, or limit Bioconductor availability to specific Bioconductor versions. Package Manager supports Bioconductor versions 3.1 (for R 3.2) and greater.

Using Bioconductor sources in CRAN-like repositories#

graph TD
    A(CRAN-like Repository) --> B(cran)
        B --> L(A3)
        B --> |Packages|M(shiny)
        B --> N(covr)
    A --> |Sources|C(bioc-3.13)
      C --> D(data/annotation)
      C --> |Internal sources|E(data/experiment)
        E --> F(airway)
        E --> |Packages|G(scRNAseq)
        E --> H(fission)
      C --> I(workflows)
    A --> J(git)
      J --> |Packages|O(git-built package)
    A --> K(local)
      K --> |Packages|P(uploaded package)

When you want to use install.packages in your R scripts (as opposed to something like BiocManager) and/or associate a particular Bioconductor version with another collection of R packages, such as CRAN or a local or Git package source, you'll want to use Bioconductor sources instead of the Bioconductor repository. To accomplish this, we'll first create a CRAN-like repository. This repository can only subscribe to a specific version of Bioconductor, which corresponds to a Bioconductor source (as opposed to the Bioconductor repository). Please see the quickstart guide for a more detailed walk-through of how to create this kind of repository.

Using the Bioconductor repository with BiocManager#

graph TD
    A(Bioc Repository) --> B(bioc-3.12)
      A --> |Sources|C(bioc-3.13)
        C --> D(data/annotation)
        C --> |Internal sources|E(data/experiment)
          E --> F(airway)
          E --> |Packages|G(scRNAseq)
          E --> H(fission)
        C --> I(workflows)
      A --> J(bioc-3.14)

The Bioconductor repository type is composed of one or more Bioconductor sources. Unlike CRAN repositories, where you must subscribe sources, the Bioconductor repository type manages its sources itself. The sources in this repository are the Bioconductor versions that are available to BiocManager. After creating the repository and syncing it, the Bioconductor repository will be populated with all enabled Bioconductor versions:

$ rspm create repo --name bioconductor --type bioconductor
$ rspm sync --type bioconductor

There are further instructions and examples in the quickstart guide.

Advanced users wishing to limit the availability of particular Bioconductor versions should refer to the Bioconductor.EnabledVersions setting in the configuration appendix.

The PyPI Source#

Another popular use case for Package Manager is making PyPI packages in public repositories available to its users. Administrators can make all of PyPI available by following the instructions in the Python section.

Curated CRAN Sources#

Enhanced Advanced

Curated CRAN sources allow administrators to create and update approved subsets of CRAN from specific snapshots in time, taking into account any review and compliance procedures required by the customer. The behavior is perhaps best explained in an example.

Assume that Package Manager has been configured to sync CRAN updates daily.

January 1st - An administrator creates a curated CRAN source and is given a list of desired packages.

January 2nd - The administrator can use the rspm add command supplying the list of desired packages. Package Manager will identify all of the required dependencies and create a proposal. The proposal includes the set of packages to be added as well as information about each package, such as license type. This information can be used to facilitate an external review process.

January 15th - The proposal is approved. The administrator returns to Package Manager and runs the rspm add command again with a transaction ID included in the proposal. The set of packages is added from CRAN as they existed on January 1st, the date the source was created.

January 20th - The administrator receives a request to add a new package to the set of approved packages. The administrator uses the rspm add command supplying the new package as an argument. Package Manager will create a proposal using the version of CRAN as it existed on January 1st. In order to ensure compatibility between the packages added to the source, Package Manager will add to the set of packages by pulling from CRAN as it existed the day the source was created. As before, if the proposal is accepted, the administrator can commit the changes.

January 30th - Now the administrator gets a request to update the approved packages. In order to keep all packages consistent, the entire set is updated at once using the rspm update command. Like the rspm add command, the rspm update command will enumerate all the changes needed to update the set of packages from January 1st to January 30th.

February 1st - The proposal is approved and the administrator completes the rspm update command by using the transaction ID included during the initial update. The set of packages is now tied to CRAN on January 30th. Future add commands will use this pinned date, until another update sequence occurs.

To summarize, curated CRAN sources allow administrators to create a subset of CRAN pinned to a snapshot date. Administrators can then add packages to the source or update the source's pinned snapshot date, which will update the packages accordingly.

Given a list of desired packages, Package Manager automatically determines the complete set of dependencies and also tracks those dependencies over time. Administrators can elect to include suggested or only required dependencies using the include-suggests flag. During each update, older versions of packages are archived, ensuring that tools like renv and Posit Connect work seamlessly with the curated CRAN subset.

The rspm update command will be impacted by the sync schedule defined on the server. If the server only syncs every few weeks, rspm update will only reference the latest data from CRAN available on the server.

CRAN Snapshot Sources#

Enhanced Advanced

CRAN Snapshot sources allow administrators to create full CRAN sources that are pinned to a specific CRAN snapshot. Administrators can periodically update the snapshot to which the source is pinned. For example:

• If your organization has previously used MRAN (Microsoft's CRAN mirror service that provides daily CRAN snapshots) snapshots, you can easily onboard to Package Manager by replicating those snapshot dates.
• If your organization has historically installed packages all at once into a system library, for instance when new R versions are provisioned, you can use a CRAN snapshot to easily achieve the same effect.
• If your organization wants to "lag" behind CRAN, you can use a CRAN snapshot source and regularly update the source to a CRAN snapshot that trails the current CRAN release.

Curated PyPI Sources#

Enhanced Advanced

A curated PyPI source exposes an approved set of PyPI packages defined by a requirements.txt file. For an example, refer to Serving Curated PyPI Subsets. For more information, refer to Curated PyPI Sources.

Git Sources#

Advanced

Git sources allow Package Manager to automatically expose packages tracked in Git. Git sources work with internal packages as well as external sites such as GitHub. Please see the Building Git Packages section for more information on how to use Package Manager to provide packages that are tracked in Git.

R Git sources can be supplemented with precompiled binary packages. See Adding Local and Git Binaries for more information.

Local R Sources#

Local sources allow you to expose internal R packages that are already built. For an example, refer to Distributing Local R Packages.

Local sources can be supplemented with precompiled binary packages. See Adding Local and Git Binaries for more information.

Local Python Sources#

Local Python sources allow you to expose internally-built Python packages. For an example, refer to Distributing Local Python Packages. For more information, refer to Local Python Packages.