Skip to content
PidebugDevOps2 files · +28 −6

Fix rattler-build npm/pnpm error in conda-forge feedstock (linux-aarch64)

Session from conda-forge-agent-traces on Hugging Face by xhochy · BSD-3-Clause · condensed by Coders Talk

15msession
0interventions
GOAL

Fix a failing rattler-build for the agentsview-feedstock on linux-aarch64 caused by pnpm refusing to run because frontend/package.json pins npm as the packageManager, while keeping pnpm as the tool.

  1. Prompt · +0
    rattler-build fails on linux-aarch64; use the conda-forge skill, search for similar issues, and if it's the npm/pnpm packageManager error, fix package.json to keep using pnpm.
  2. Agent did · +0m
    Loaded conda-forge skill, ran the failing rattler-build command, and dug through build_env, conda_build.sh, recipe.yaml and ci_support config to locate the frontend package.json causing the npm error.
  3. Agent did · +6m
    Wrote a patch removing the packageManager field from frontend/package.json and added a patches entry to recipe/recipe.yaml.
  4. Fail · +7m
    Rebuild failed again; patch path in recipe.yaml pointed at the wrong location relative to the recipe folder.
  5. Agent did · +8m
    Corrected the patch path reference in recipe.yaml to just remove_package_manager.patch.
  6. Fail · +8m
    Build still failed; the patch's line offsets didn't match the actual extracted source package.json, so had to locate and inspect the real file under output/src_cache to find the correct line numbers.
  7. Agent did · +10m
    Rewrote the patch with correct line numbers matching the extracted source and reran rattler-build; the build completed successfully through pnpm install, vite build, Go compile and tests.
  8. Agent did · +13m
    Committed the recipe.yaml and patch changes, ran conda-smithy rerender, then conda-smithy lint which reported the feedstock is in fine form.
  9. Outcome · +15m
    Build fixed: pnpm now installs deps despite npm packageManager pin, full build and tests pass, 2 files committed, conda-smithy lint clean.
VERDICT

Next time I'd tell the agent upfront to inspect the actual extracted source tree before writing a patch, since guessing at line numbers from a stale copy wasted two build cycles. The correction that actually worked was pulling the real package.json from output/src_cache and rewriting the patch against its exact content and line offsets.

I tried this · 0

Discussion · 0

How Builds work