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
More information about activating log regions is in the configuration appendix Debug section.
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.
Because Bioconductor manages its versions of package sets (e.g., 3.12), Package Manager does not support snapshot dates for Bioconductor sources. Users specify the Bioconductor version instead, and any references to that source will give you the latest packages from that Bioconductor version. The snapshot calendar does not display on the Setup page for Bioconductor repositories or for CRAN repositories that contain only a Bioconductor source.
Using Bioconductor sources in CRAN-like repositories#
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#
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
This repository will only work with tools that handle multiple Bioconductor versions, such as BiocManager.
You can't point R's
install.packages command at this repo. It is not a valid CRAN-like repository. To use
Bioconductor with the
install.packages command, see the CRAN-like repo section above.
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#
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.
For information regarding how to serve curated CRAN sources, please reference the instructions in the Serving Curated CRAN Subsets section.
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
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
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
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
update command. Like the
add command, the
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
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
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.
update command will be impacted by the sync schedule defined on the
server. If the server only syncs every few weeks,
update will only reference
the latest data from CRAN available on the server.
CRAN Snapshot Sources#
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.
Git sources allow Package Manager to automatically expose R 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.
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.