Skip to content

vibe 0.1.195

Choose a tag to compare

View all tags
@github-actions github-actions released this 06 Nov 10:16
v0.1.195
5361be0
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Dotnet feature: let code that resolves packages itself find the host's cache, and keep link-nuget's settings after sudo (#16)

A RazorLight template test failed in a sandbox with Cannot find compilation library location for package 'System.Security.Cryptography.Pkcs'. The package was in the host's cache, which the sandbox mounts read-only as NuGet's fallback folder. NuGet and MSBuild use fallback folders, but code that finds a package's assemblies itself does not. Microsoft.Extensions.DependencyModel, which RazorLight uses, only looks in the app's probing paths, then NUGET_PACKAGES, then ~/.nuget/packages. That only bites a package whose assemblies aren't copied to the output folder, such as a compile-only one.

Changes

  1. link-nuget sets GenerateRuntimeConfigDevFile=true in fallback mode. The SDK then writes the fallback folder into bin/**/*.runtimeconfig.dev.json as a probing path, which DependencyModel reads. It is removed again in the shared and overlay modes, where the host cache is NUGET_PACKAGES. This keeps the fallback design. Pointing NUGET_PACKAGES at the read-only cache would break restores that need a package the host lacks, as docs/plan-nuget-feeds.md already notes.
  2. link-nuget reads the variables the sandbox was made with from PID 1's environment when its own lacks them. The session-start nudge runs on-start under sudo, which drops SBX_HOST_NUGET_PACKAGES and the like. So every run after the first boot logged "nothing to do". start-clipboard already does the same for its own variable. A changed script still only reaches a sandbox by rebuilding it, so this fixes a misleading log and lets a failed first boot be put right at the next start. It does not make existing sandboxes pick up new settings without a rebuild.
  3. Tests and readme. A new test builds a package-less project with the real SDK, using the variables link-nuget persists. It checks that runtimeconfig.dev.json names the fallback folder and that the app runs. A second part checks that no such file is written without the setting. It skips without dotnet. Other tests cover the PID 1 read, and the test harness now uses an empty PID 1 environment so results don't depend on the machine running them. The readme explains both changes and that each build leaves a runtimeconfig.dev.json in bin/.

Verified

  • Reproduced under a real test host. A net8.0 xunit project with RazorLight and a compile-only Pkcs reference, with the host cache as a read-only fallback, failed. The same project passed with the variable set. It ran on the .NET 10 runtime with roll-forward, not a real runtime 8.
  • The app runs with nonexistent probing paths. An app ran fine with two paths that don't exist added to its runtimeconfig.dev.json. That check was by hand.
  • Go suite. go test ./... passes.

Not verified

  • No re-composed sandbox on the final code. The agent in the yumbi sandbox confirmed the setting and the resulting file on an earlier build, before the PID 1 read was added.
  • Host side of the new runtimeconfig.dev.json files. I haven't run a sandbox-written one on a real host.
  • CI hasn't run.

Notes

  • Existing sandboxes need a rebuild (vibe -C) once to get the setting.
  • The df6100c commit message overstates the PID 1 read, saying a changed script reaches existing sandboxes without a rebuild. The readme is correct. I didn't rewrite history. Squash-merging avoids carrying the message.

🤖 Generated with Claude Code

To install:

  • Linux/macOS: curl -fsSL https://raw.githubusercontent.com/fluffynuts/vibe/master/install.sh | sh
  • Windows: irm https://raw.githubusercontent.com/fluffynuts/vibe/master/install.ps1 | iex
  • Manual: download the zip for your platform (below), unzip it anywhere, and run
    vibe --install from the folder it makes.

To upgrade, run the same command again, or vibe --upgrade once vibe is installed.

Platform Zip
Linux (x86-64) vibe-linux-amd64.zip
Linux (ARM) vibe-linux-arm64.zip
macOS (Apple Silicon) vibe-macos-arm64.zip
macOS (Intel) vibe-macos-amd64.zip
Windows (x86-64) vibe-windows-amd64.zip
Windows (ARM) vibe-windows-arm64.zip

SHA256SUMS holds each zip's checksum. The install scripts and vibe --upgrade check it.

macOS: the binary isn't signed, so if it's blocked after downloading in a browser, run
xattr -dr com.apple.quarantine <folder> once.

What's Changed

  • Dotnet feature: let code that resolves packages itself find the host's cache, and keep link-nuget's settings after sudo by @fluffynuts in #16

Full Changelog: v0.1.190...v0.1.195

Contributors

fluffynuts
Assets 9
Loading