Wire OSP dependency resolution through R-universe

[Felixmil]

Wire OSP dependency resolution through R-universe

Follow-up to #1, which proposes and gets a decision on adopting R-universe. The registry is live and the packages that matter most are already building and installable from the universe. This issue is about the remaining work that actually changes how people build on OSP: making the universe the standard channel for resolving dependencies between OSP packages, and for downstream packages that depend on the stack. It does not re-argue the decision (see #1).

The agreed constraint from #1 holds: R-universe is additional. publish.yml keeps cutting GitHub releases and binaries as today; the universe builds on top of those releases and becomes the channel for dependency resolution, not a replacement for releases.

Where we are (2026-07-21)

The core stack is green and installable from the universe today: rSharp, ospsuite.utils, tlf, ospsuite, ospsuite.plots (plus ospsuite.globalsensitivity). The main historical blocker (rSharp's .onLoad() hard-erroring without a .NET runtime) is resolved: Open-Systems-Pharmacology/rSharp#224 and Open-Systems-Pharmacology/OSPSuite-R#1991 are merged.

install.packages(
  "ospsuite",
  repos = c(OSP = "https://open-systems-pharmacology.r-universe.dev", getOption("repos"))
)

That is enough for the common case. The steps below are what turn it into the standard way OSP packages resolve each other.

Steps that matter

Ordered so the stack is never left in a broken state: every step is additive (both the existing Remotes: chain and the universe keep working) until the last step, by which point every consumer can already resolve from the universe.

• Agree the canonical mechanism and the dev-build story up front, so the changes below all aim at the same target. For released builds the goal is universe-on-repos / Additional_repositories with no Remotes: field, instead of the Remotes: ...@*release GitHub chain. Dev-against-dev is a temporary state that adds a Remotes: entry + an Imports version floor, exactly the pattern the R Packages book prescribes for depending on the development version of a package (a Remotes: entry plus a floor only the dev build satisfies, as made by usethis::use_dev_package()). Because OSP dev builds pin each other, going dev on one package pulls the connected dev set: document this as the intended dev workflow, not a bug. The concrete DESCRIPTION states (released, dev-against-sibling, released again) and the two OSP caveats are worked out in the comment below.
• Land Expose an extra-repositories input in R-CMD-check workflows / setup-r-env Workflows#242, which adds an extra-repositories input to R-CMD-check-build.yaml / setup-r-env. This must come before switching CI to the universe: the reusable workflow currently exposes no such input, so without it the universe route is not reachable through that workflow.
• In each package's GitHub Actions, add the universe to repos (via the new extra-repositories input, or extra-repositories: on r-lib/actions/setup-r for packages not using the reusable workflow). Purely additive: CI can now resolve OSP dependencies as universe binaries/source while the Remotes: chain still works too. This also sidesteps the flaky multi-layer GitHub GraphQL resolution.
• In each OSP package that depends on other OSP packages, declare Additional_repositories: https://open-systems-pharmacology.r-universe.dev in DESCRIPTION so R CMD check and source installs resolve siblings from the universe. Also additive, and it coexists with any existing Remotes: field.
• Once CI and DESCRIPTION on every package can reach the universe (the two steps above), retire the OSP-to-OSP Remotes: chain for released builds, making the universe the canonical resolution channel. Safe only at this point, because nothing still depends on the Remotes: chain to find its siblings.
• Update each package README with the two install paths, released as the primary one. Released version from the universe with plain base R (binaries, no extra tooling):

  install.packages(
    "ospsuite",
    repos = c(OSP = "https://open-systems-pharmacology.r-universe.dev", getOption("repos"))
  )

  Development version from GitHub with pak (kept for dev installs, where you want the unreleased build rather than the universe's released one):

  pak::pak("Open-Systems-Pharmacology/OSPSuite-R")

  Keep the existing GitHub-release install path documented as still supported.
• Document the runtime gotcha for downstream maintainers: installing is not running, the .NET runtime is a separate machine prerequisite. Note the OSP reusable workflow already installs .NET (via setup-r-env), so this only bites CI that does not use it (e.g. a plain r-lib/actions setup on macOS runners, which ship no .NET by default).

Reference

The downstream-install behavior was validated with a minimal throwaway package (Imports: ospsuite, ospsuite.plots, universe declared in Additional_repositories): https://github.com/Felixmil/dummyosp. Its README has runnable snippets, a provenance check, and the platform/runtime and dependency-resolution findings that back the steps above.

[Felixmil]

How release vs. dev dependencies work under this setup

@Yuri05 @PavelBal

A note on what the day-to-day DESCRIPTION looks like once the universe is the resolution channel, and how it differs from the current Remotes: ...@*release approach.

The key change: in the steady (released) state there is no Remotes: field at all. An OSP package just declares its OSP siblings in Imports like any other dependency, and names the universe once in Additional_repositories. Resolution finds the released sibling in the universe, so the @*release pin (and the sync-remotes machinery that maintains it) is no longer needed. Remotes: reappears only as a temporary state while developing against an unreleased sibling, and disappears again once that sibling is released.

Using ospsuite (which imports ospsuite.utils) as the example, the DESCRIPTION evolves like this, in the style of the R Packages book:

Released (steady state) -->     Dev against sibling -->          Released again
---------------------------     ------------------------------   ---------------------------
Package: ospsuite               Package: ospsuite                Package: ospsuite
Version: 12.4.4                  Version: 12.4.4.9000             Version: 12.5.0
Imports:                        Imports:                         Imports:
    ospsuite.utils (>= 1.11.1)      ospsuite.utils (>= 1.11.1.9000)  ospsuite.utils (>= 1.12.0)
Additional_repositories:        Additional_repositories:         Additional_repositories:
    https://open-...universe.dev    https://open-...universe.dev     https://open-...universe.dev
                                Remotes:
                                    Open-Systems-Pharmacology/OSPSuite.RUtils

Left / right (released): no Remotes:. The universe serves ospsuite.utils, and the Imports version floor is satisfied by the released build there. This is the normal, permanent state, and it replaces today's Remotes: ospsuite.utils=...@*release.

Middle (developing against an unreleased ospsuite.utils): add a bare Remotes: entry for its GitHub repo and raise the Imports floor to a .9000-style version that only the dev build satisfies (this is what usethis::use_dev_package("ospsuite.utils") writes). The floor is essential: pak treats Remotes: purely as a source hint and will otherwise keep taking the released build from the universe, since it still satisfies a plain >= 1.11.1. Only a floor the released build fails forces the fall-through to the GitHub dev build. When ospsuite.utils cuts its next release, drop the Remotes: entry and set the floor to the released version (right column).

Dev versions cascade, so migrate the connected set together

Because the OSP dev builds pin each other through their own Remotes:, taking one package at its dev version generally pulls the connected dev set. For example, dev ospsuite.plots carries a Remotes: for dev ospsuite.utils; combining that with a universe-served (released) ospsuite that wants released ospsuite.utils cannot be solved. What actually forces this is a package requiring a version the universe cannot serve (a dev-only floor); that forces the GitHub dev build and drags its dev siblings in. So "go dev" is a decision about the connected set, not a single package, and the migration should move that set together.

One clarification, since it is easy to over-worry: a leftover Remotes: field on its own is not fatal. With the universe on repos and no dev floor, pak treats Remotes: as a source hint and still takes the released sibling from the universe (verified: a package carrying Remotes: OSPSuite.Plots or ...@*release still resolves ospsuite.plots from the universe). Stray @*release Remotes: fields do not break resolution, but they are dead configuration that muddies which channel is authoritative, so drop them stack-wide as part of the move.

Resolving a cascade conflict

When going dev on one package produces a conflict on a shared dependency, the fix is to pull that conflicted dependency into the dev set explicitly: add it as a Remotes: entry and give it an Imports version floor only its dev build satisfies (the same use_dev_package() pattern, applied to the conflicted sibling too).

Concretely, developing dummyosp against dev ospsuite.plots conflicts on the shared ospsuite.utils. Adding ospsuite.utils to both fields resolves it:

Conflicts -->                        Resolves -->
---------------------------------    -----------------------------------
Imports:                             Imports:
    ospsuite                             ospsuite
    ospsuite.plots (>= 1.3.0.9000)       ospsuite.plots (>= 1.3.0.9000)
                                         ospsuite.utils (>= 1.11.1.9000)
Remotes:                             Remotes:
    ospsuite.plots=OSP/OSPSuite.Plots    ospsuite.plots=OSP/OSPSuite.Plots
                                         ospsuite.utils=OSP/OSPSuite.RUtils

With that, resolution succeeds: ospsuite.plots and ospsuite.utils come from GitHub as dev builds while ospsuite still comes from the universe as a release.

Use the named Remotes: form when repo name != package name (general pak gotcha, not OSP-specific)

Use the named Remotes: form pkg=owner/repo (e.g. ospsuite.utils=Open-Systems-Pharmacology/OSPSuite.RUtils), which is what the OSP DESCRIPTIONs already use. The reason is simply that the OSP repo names differ from their package names (OSPSuite.RUtils -> ospsuite.utils, OSPSuite-R -> ospsuite, TLF-Library -> tlf). pak matches a Remotes: entry to an Imports requirement by package name, and for a bare owner/repo it takes that name from the repo basename, so Open-Systems-Pharmacology/OSPSuite.RUtils is read as package OSPSuite.RUtils, never matches the ospsuite.utils requirement, and the solve fails with Can't install dependency .... The pkg=owner/repo form states the package name explicitly, so the match works. (A bare remote is fine only when the repo basename already equals the package name, e.g. Open-Systems-Pharmacology/rSharp for rSharp.)