chore(deps): update dependency nbafrank/uvr to v0.4.5 #148

Merged
automation-bot merged 1 commit from renovate/nbafrank-uvr-0.x into main 2026-08-04 02:32:05 +00:00
Owner

This PR contains the following updates:

Package Update Change
nbafrank/uvr patch v0.4.4v0.4.5

Release Notes

nbafrank/uvr (nbafrank/uvr)

v0.4.5

Compare Source

The community release. Four contributors filed thirteen pull requests in
three days, and this ships nearly all of them: shell activation (the first
feature from the uv-parity roadmap), a sysreqs subsystem rebuilt end to
end, binary-repo selection driven by Posit's live catalogue instead of a
table that went stale, and a conformance suite that runs the real release
binary natively on twenty-nine Linux distributions — which promptly found
bugs users had been hitting silently. Three independent adversarial
reviews ran before this tag; the correctness fixes they turned up are
included.

  • Package names containing dots no longer install the wrong package
    (#​222). [dependencies.shiny.i18n] is parsed by TOML as package shiny
    with a sub-key, so uvr silently installed shiny and its 30 dependencies
    instead; [dependencies.R.utils] silently installed nothing at all; and
    org.Hs.eg.db resolved from CRAN rather than Bioconductor. Every one
    failed silently — the wrong thing installed, with no warning. Unexpected
    sub-keys are now a parse error that reconstructs the full dotted name by
    walking the nested table chain, so multi-segment Bioconductor names
    (org.Hs.eg.db, TxDb.Hsapiens.UCSC.hg38.knownGene) are quoted and
    suggested correctly rather than truncated to their first two segments.

  • One sysreqs API request per sync instead of one per package: a
    68-package sync made 68 requests where the batched endpoint answers in
    one. The batched response also names transitive requirements as separate
    entries, which fixes a pre-existing misattribution (everything gert
    pulled in was credited to gert itself).

  • Bioconductor packages whose declared SystemRequirements match no
    vendored rule are now reported as unverified. Previously, when the
    sysreqs index fetched successfully, a Bioconductor package that took the
    local-rules path and matched nothing produced no output at all — neither
    missing, nor degraded, nor skipped. A check that never happened read as a
    check that passed.

  • uvr no longer tells zypper, pacman and yum-only hosts to run apt-get
    (#​226). The sysreqs hint probed for apk and dnf and then guessed
    apt-get, so on openSUSE the package name was right and the command
    didn't exist — on the one class of host where uvr can't run the install
    itself and the hint is therefore the whole deliverable. Detection now
    covers apk, dnf, microdnf, yum, zypper, pacman and apt-get, and when it
    recognizes none of them it names the packages and says to use the system
    package manager rather than inventing a command. uvr doctor's C-compiler
    advice is fixed the same way — it hardcoded a Debian command and a
    Debian package name.

  • TLS failures say they are TLS failures (#​227). Network error: error sending request for url (...) was all a user saw when a certificate was
    rejected, because reqwest::Error's own Display renders only the
    outermost layer and the real cause sits in the source() chain. Network
    errors now include the underlying cause, and a certificate failure adds a
    hint pointing at the system trust store and SSL_CERT_FILE instead of
    leaving it indistinguishable from being offline.

  • System dependencies are resolved on distributions Posit's sysreqs API
    doesn't cover (#​207). SystemRequirements was only ever read from the
    resolved repository's PACKAGES index, and CRAN's index doesn't publish
    that field — so on Alpine every CRAN package reached the vendored local
    rules with nothing to match, and uvr sync --install-system-deps went
    straight into a source build that failed on the missing library (terra
    gdal-config not found, unitslibudunits2.so was not found)
    without printing a sysreqs warning either. The check now runs after the
    tarballs are downloaded and reads SystemRequirements from each one's
    DESCRIPTION, which is where the field is actually published.

  • Binary package repos are chosen from Posit's live platform catalog, and the
    choice now accounts for the host architecture. uvr matched a hardcoded
    slug → repo table with no notion of arch, but only rhel9, rhel10,
    noble, resolute and manylinux_2_28 carry arm64 builds — and P3M
    degrades to source when a repo has no build for the caller's architecture.
    An arm64 host on Ubuntu 22.04, Debian 12, RHEL 8 or openSUSE was therefore
    compiling every package while the portable manylinux_2_28 repo, which does
    build for arm64, sat unused. uvr now reads GET /__api__/status (cached
    daily) and picks a repo that actually serves this distro on this
    architecture. The compiled-in table still answers when the endpoint is
    unreachable, and --distribution still wins over both.

  • Oracle Linux gets binary packages, not just system dependencies (#​209
    follow-up). ID="ol" was aliased onto RHEL for sysreqs but not for the P3M
    slug, so OL hosts resolved their system libraries correctly and then
    compiled every package from source.

  • Rocky/Alma 8 and CentOS Stream 9/10 get authoritative sysreqs answers
    instead of the local-rules fallback. Posit's catalogs serve rockylinux
    from 9 on and centos only through 8, so those hosts fell back to the
    vendored rules and printed a degraded-check warning for distros Posit does
    cover, under their RHEL name. Catalogs are now asked under a name they
    publish. The
    local rules keep the unaliased name on purpose — they are not
    interchangeable there: rockylinux 8 carries leptonica-devel where
    redhat 8 carries nothing, and centos 8 wants libarchive-devel where
    redhat 8 says libarchive.

  • Glibc hosts with musl installed get glibc R builds again. linux_is_musl()
    answered yes whenever a musl dynamic loader existed anywhere under /lib,
    which is true of any glibc machine that has the musl package — installing
    Rust's x86_64-unknown-linux-musl target pulls it in, so this hit developer
    boxes routinely. Those hosts were handed musllinux R, which dies in the
    loader (Error relocating /lib/libz.so.1: __snprintf_chk: symbol not found),
    and were also denied P3M binary packages entirely, since that path skips musl
    hosts. Detection now asks ldd --version first — the same question
    install.sh asks when it picks which uvr binary the host gets — and glibc
    wins when both loaders are present.

  • A freshly installed R is checked before being called installed. The install
    verified that bin/R exists but never ran it, so an R that could not start
    was reported as a success and failed later somewhere less obvious. On macOS
    and Linux uvr r install now starts the new R and asks it for its version,
    then removes the install and says what likely went wrong if that produces
    nothing. Windows is exempt: bin/R.exe there is a front-end that re-spawns
    the real binary, and the probe returns nothing for a freshly unzipped
    install that runs perfectly well.

  • uvr r install devel and uvr r install next work, and say what they are.
    The rolling channels are published for every platform and architecture, but
    uvr rejected them as invalid versions and hid them from uvr r list --all.
    They now install under their own name and are labelled [unstable] in the
    listing and warned about at install time — they are rebuilt continuously, so
    pinning one is not reproducible.

  • Windows can install R 3.6.3 again. Availability was modelled as a single
    floor shared by macOS and Windows (>= 4.1.0), but the two platforms differ
    and Windows is not contiguous: the CDN publishes 3.6.3, nothing from 3.6.4
    through 4.0.5, then 4.1.0 onwards. A floor either rejected 3.6.3, which
    exists, or advertised thirty versions that do not, so availability is now a
    per-platform predicate.

  • System dependencies are resolved on RHEL and its rebuilds (#​209). uvr asked
    both sysreqs catalogs under the raw /etc/os-release identity, which neither
    speaks: Posit's API answers Unsupported system for rhel/8.10 but
    answers normally for redhat/8, and every vendored rule is written as
    redhat with versions: ["8"]. RHEL hosts therefore got nothing from the
    API and nothing from the local fallback either. The (ID, VERSION_ID) pair
    is now mapped onto the catalogs' vocabulary — rhelredhat,
    rocky/almalinuxrockylinux, slessle, openSUSE variants →
    opensuse — with the RHEL family truncated to its major release. Oracle
    Linux (ol) joins them: it is a RHEL rebuild that neither catalog knew.
    Coverage still varies behind the mapping — the API serves rockylinux 9/10
    but not 8, and rejects fedora and alpine outright — so the local rules
    remain the backstop for those.

  • Shell activation (#​177#​180): source .uvr/activate puts the project's
    managed R and isolated library into the current shell, so a bare R or
    Rscript uses the project with no uvr run prefix; deactivate restores
    it. Shims for bash/zsh/sh, fish, and PowerShell are written by uvr init
    (or uvr activate --write-shim). They hold no paths — each asks uvr to
    recompute the environment as it is sourced, so uvr r use / uvr r pin
    can never leave a stale activation behind. Optionally prefixes the prompt
    with the project name via [activate] prompt = true or
    UVR_ACTIVATE_PROMPT; off by default.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • Between 12:00 AM and 03:59 AM (* 0-3 * * *)
  • Automerge
    • Between 12:00 AM and 03:59 AM (* 0-3 * * *)

🚦 Automerge: Enabled.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate.

This PR contains the following updates: | Package | Update | Change | |---|---|---| | [nbafrank/uvr](https://github.com/nbafrank/uvr) | patch | `v0.4.4` → `v0.4.5` | --- ### Release Notes <details> <summary>nbafrank/uvr (nbafrank/uvr)</summary> ### [`v0.4.5`](https://github.com/nbafrank/uvr/blob/HEAD/CHANGELOG.md#v045-2026-08-03) [Compare Source](https://github.com/nbafrank/uvr/compare/v0.4.4...v0.4.5) The community release. Four contributors filed thirteen pull requests in three days, and this ships nearly all of them: shell activation (the first feature from the uv-parity roadmap), a sysreqs subsystem rebuilt end to end, binary-repo selection driven by Posit's live catalogue instead of a table that went stale, and a conformance suite that runs the real release binary natively on twenty-nine Linux distributions — which promptly found bugs users had been hitting silently. Three independent adversarial reviews ran before this tag; the correctness fixes they turned up are included. - **Package names containing dots no longer install the wrong package** ([#&#8203;222](https://github.com/nbafrank/uvr/issues/222)). `[dependencies.shiny.i18n]` is parsed by TOML as package `shiny` with a sub-key, so uvr silently installed `shiny` and its 30 dependencies instead; `[dependencies.R.utils]` silently installed nothing at all; and `org.Hs.eg.db` resolved from CRAN rather than Bioconductor. Every one failed silently — the wrong thing installed, with no warning. Unexpected sub-keys are now a parse error that reconstructs the full dotted name by walking the nested table chain, so multi-segment Bioconductor names (`org.Hs.eg.db`, `TxDb.Hsapiens.UCSC.hg38.knownGene`) are quoted and suggested correctly rather than truncated to their first two segments. - **One sysreqs API request per sync instead of one per package**: a 68-package sync made 68 requests where the batched endpoint answers in one. The batched response also names transitive requirements as separate entries, which fixes a pre-existing misattribution (everything `gert` pulled in was credited to `gert` itself). - Bioconductor packages whose declared `SystemRequirements` match no vendored rule are now reported as unverified. Previously, when the sysreqs index fetched successfully, a Bioconductor package that took the local-rules path and matched nothing produced no output at all — neither missing, nor degraded, nor skipped. A check that never happened read as a check that passed. - uvr no longer tells zypper, pacman and yum-only hosts to run `apt-get` ([#&#8203;226](https://github.com/nbafrank/uvr/issues/226)). The sysreqs hint probed for `apk` and `dnf` and then *guessed* `apt-get`, so on openSUSE the package name was right and the command didn't exist — on the one class of host where uvr can't run the install itself and the hint is therefore the whole deliverable. Detection now covers apk, dnf, microdnf, yum, zypper, pacman and apt-get, and when it recognizes none of them it names the packages and says to use the system package manager rather than inventing a command. `uvr doctor`'s C-compiler advice is fixed the same way — it hardcoded a Debian command *and* a Debian package name. - TLS failures say they are TLS failures ([#&#8203;227](https://github.com/nbafrank/uvr/issues/227)). `Network error: error sending request for url (...)` was all a user saw when a certificate was rejected, because `reqwest::Error`'s own `Display` renders only the outermost layer and the real cause sits in the `source()` chain. Network errors now include the underlying cause, and a certificate failure adds a hint pointing at the system trust store and `SSL_CERT_FILE` instead of leaving it indistinguishable from being offline. - System dependencies are resolved on distributions Posit's sysreqs API doesn't cover ([#&#8203;207](https://github.com/nbafrank/uvr/issues/207)). `SystemRequirements` was only ever read from the resolved repository's `PACKAGES` index, and CRAN's index doesn't publish that field — so on Alpine every CRAN package reached the vendored local rules with nothing to match, and `uvr sync --install-system-deps` went straight into a source build that failed on the missing library (`terra` → `gdal-config not found`, `units` → `libudunits2.so was not found`) without printing a sysreqs warning either. The check now runs after the tarballs are downloaded and reads `SystemRequirements` from each one's DESCRIPTION, which is where the field is actually published. - Binary package repos are chosen from Posit's live platform catalog, and the choice now accounts for the host architecture. uvr matched a hardcoded slug → repo table with no notion of arch, but only `rhel9`, `rhel10`, `noble`, `resolute` and `manylinux_2_28` carry arm64 builds — and P3M degrades to *source* when a repo has no build for the caller's architecture. An arm64 host on Ubuntu 22.04, Debian 12, RHEL 8 or openSUSE was therefore compiling every package while the portable `manylinux_2_28` repo, which does build for arm64, sat unused. uvr now reads `GET /__api__/status` (cached daily) and picks a repo that actually serves this distro on this architecture. The compiled-in table still answers when the endpoint is unreachable, and `--distribution` still wins over both. - Oracle Linux gets binary packages, not just system dependencies ([#&#8203;209](https://github.com/nbafrank/uvr/issues/209) follow-up). `ID="ol"` was aliased onto RHEL for sysreqs but not for the P3M slug, so OL hosts resolved their system libraries correctly and then compiled every package from source. - Rocky/Alma 8 and CentOS Stream 9/10 get authoritative sysreqs answers instead of the local-rules fallback. Posit's catalogs serve `rockylinux` from 9 on and `centos` only through 8, so those hosts fell back to the vendored rules and printed a degraded-check warning for distros Posit does cover, under their RHEL name. Catalogs are now asked under a name they publish. The local rules keep the unaliased name on purpose — they are not interchangeable there: `rockylinux` 8 carries `leptonica-devel` where `redhat` 8 carries nothing, and `centos` 8 wants `libarchive-devel` where `redhat` 8 says `libarchive`. - Glibc hosts with musl installed get glibc R builds again. `linux_is_musl()` answered yes whenever a musl dynamic loader existed anywhere under `/lib`, which is true of any glibc machine that has the `musl` package — installing Rust's `x86_64-unknown-linux-musl` target pulls it in, so this hit developer boxes routinely. Those hosts were handed musllinux R, which dies in the loader (`Error relocating /lib/libz.so.1: __snprintf_chk: symbol not found`), and were also denied P3M binary packages entirely, since that path skips musl hosts. Detection now asks `ldd --version` first — the same question `install.sh` asks when it picks which uvr binary the host gets — and glibc wins when both loaders are present. - A freshly installed R is checked before being called installed. The install verified that `bin/R` exists but never ran it, so an R that could not start was reported as a success and failed later somewhere less obvious. On macOS and Linux `uvr r install` now starts the new R and asks it for its version, then removes the install and says what likely went wrong if that produces nothing. Windows is exempt: `bin/R.exe` there is a front-end that re-spawns the real binary, and the probe returns nothing for a freshly unzipped install that runs perfectly well. - `uvr r install devel` and `uvr r install next` work, and say what they are. The rolling channels are published for every platform and architecture, but uvr rejected them as invalid versions and hid them from `uvr r list --all`. They now install under their own name and are labelled `[unstable]` in the listing and warned about at install time — they are rebuilt continuously, so pinning one is not reproducible. - Windows can install R 3.6.3 again. Availability was modelled as a single floor shared by macOS and Windows (`>= 4.1.0`), but the two platforms differ and Windows is not contiguous: the CDN publishes 3.6.3, nothing from 3.6.4 through 4.0.5, then 4.1.0 onwards. A floor either rejected 3.6.3, which exists, or advertised thirty versions that do not, so availability is now a per-platform predicate. - System dependencies are resolved on RHEL and its rebuilds ([#&#8203;209](https://github.com/nbafrank/uvr/issues/209)). uvr asked both sysreqs catalogs under the raw `/etc/os-release` identity, which neither speaks: Posit's API answers `Unsupported system` for `rhel`/`8.10` but answers normally for `redhat`/`8`, and every vendored rule is written as `redhat` with `versions: ["8"]`. RHEL hosts therefore got nothing from the API and nothing from the local fallback either. The `(ID, VERSION_ID)` pair is now mapped onto the catalogs' vocabulary — `rhel` → `redhat`, `rocky`/`almalinux` → `rockylinux`, `sles` → `sle`, openSUSE variants → `opensuse` — with the RHEL family truncated to its major release. Oracle Linux (`ol`) joins them: it is a RHEL rebuild that neither catalog knew. Coverage still varies behind the mapping — the API serves `rockylinux` 9/10 but not 8, and rejects `fedora` and `alpine` outright — so the local rules remain the backstop for those. - **Shell activation** ([#&#8203;177](https://github.com/nbafrank/uvr/issues/177)–[#&#8203;180](https://github.com/nbafrank/uvr/issues/180)): `source .uvr/activate` puts the project's managed R and isolated library into the current shell, so a bare `R` or `Rscript` uses the project with no `uvr run` prefix; `deactivate` restores it. Shims for bash/zsh/sh, fish, and PowerShell are written by `uvr init` (or `uvr activate --write-shim`). They hold no paths — each asks uvr to recompute the environment as it is sourced, so `uvr r use` / `uvr r pin` can never leave a stale activation behind. Optionally prefixes the prompt with the project name via `[activate] prompt = true` or `UVR_ACTIVATE_PROMPT`; off by default. </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - Between 12:00 AM and 03:59 AM (`* 0-3 * * *`) - Automerge - Between 12:00 AM and 03:59 AM (`* 0-3 * * *`) 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4yODMuMCIsInVwZGF0ZWRJblZlciI6IjQzLjI4My4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
chore(deps): update dependency nbafrank/uvr to v0.4.5
All checks were successful
ci/crow/cron/process-updates/10 Pipeline was successful
ci/crow/cron/process-updates/4 Pipeline was successful
ci/crow/cron/process-updates/13 Pipeline was successful
ci/crow/cron/process-updates/14 Pipeline was successful
ci/crow/cron/process-updates/15 Pipeline was successful
ci/crow/cron/process-updates/16 Pipeline was successful
ci/crow/cron/process-updates/11 Pipeline was successful
ci/crow/cron/process-updates/18 Pipeline was successful
ci/crow/cron/process-updates/17 Pipeline was successful
ci/crow/cron/process-updates/12 Pipeline was successful
ci/crow/cron/process-updates/6 Pipeline was successful
ci/crow/cron/process-updates/5 Pipeline was successful
ci/crow/cron/process-updates/1 Pipeline was successful
ci/crow/cron/process-updates/2 Pipeline was successful
ci/crow/cron/process-updates/7 Pipeline was successful
ci/crow/cron/process-updates/8 Pipeline was successful
ci/crow/cron/process-updates/9 Pipeline was successful
ci/crow/cron/process-updates/3 Pipeline was successful
e02be7518f
automation-bot scheduled this pull request to auto merge when all checks succeed 2026-08-04 02:32:04 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
devxy/build-cran-binaries!148
No description provided.