fix(sdist): regenerate Cargo.lock when workspace members are removed

[ckhordiasma]

Summary

Fixes #2609.

When maturin builds an sdist from a workspace, rewrite_cargo_toml strips workspace members
not needed by the package. The Cargo.lock was copied verbatim and still referenced those
removed crates, so cargo build --locked inside the sdist would fail.

After all sdist entries are assembled in the virtual writer, materialize them to a temp
directory, run cargo update --workspace to reconcile the lockfile, and replace the tracker
entry with the regenerated Cargo.lock.

Changes

• Add materialize_to and replace_bytes helpers on VirtualWriter<SDistWriter>
• Add regenerate_cargo_lock step after add_workspace_manifest in the sdist builder
• Use cargo update --workspace instead of cargo generate-lockfile to preserve existing dependency pins
• Only trigger lockfile regeneration when workspace members are actually stripped (not for any multi-member workspace)
• Propagate --offline flag to the cargo subprocess
• Degrade gracefully when cargo update --workspace fails (e.g. missing .cargo/config.toml for private registries in the temp dir) — warn and keep the original lockfile instead of failing the build
• Use --manifest-path explicitly instead of relying on current_dir + cargo's upward search

Review feedback addressed

Per review from @messense:

1. cargo generate-lockfile re-resolves to latest → replaced with cargo update --workspace which preserves existing pins. Test pins itoa to 1.0.1 with --precise and verifies it survives.
2. Trigger condition too coarse → now compares original workspace member count against kept members (main crate + same-workspace path deps). Test uses a [patch.crates-io] with a relative path that breaks in the temp dir, proving unnecessary regeneration is skipped.
3. Offline / cargo config → propagates --offline; degrades to warning + original lockfile on failure. Test uses a [patch] relative path to trigger failure and verifies the build succeeds via graceful degradation.
4. Smaller points → --manifest-path used explicitly; error message spacing fixed; test asserts devtool/rand are absent and pinned versions are preserved.

Test plan

• cargo test sdist_workspace_removed_members_cargo_lock — stripped members are pruned, pins preserved, --frozen succeeds
• cargo test sdist_workspace_all_members_kept_skips_regeneration — no unnecessary regeneration when all members are path deps
• cargo test sdist_workspace_lockfile_regen_graceful_degradation — build succeeds with warning when cargo update fails
• All sdist tests pass
• cargo fmt clean

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes sdists produced from Cargo workspaces where rewrite_cargo_toml removes unneeded workspace members but the copied Cargo.lock still references them, causing cargo build --locked / cargo metadata --frozen to fail inside the unpacked sdist.

Changes:

• Add VirtualWriter<SDistWriter>::materialize_to and replace_bytes helpers to support post-processing tracked sdist entries.
• After assembling workspace-related sdist entries, materialize the sdist to a temp dir, run cargo generate-lockfile, and replace the sdist’s Cargo.lock with the regenerated version.
• Add a regression test that constructs a two-member workspace, builds an sdist for one member, unpacks it, and asserts cargo metadata --frozen succeeds.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
tests/run/sdist.rs	Adds regression coverage ensuring workspace-member sdists have a usable Cargo.lock.
src/source_distribution/mod.rs	Adds regenerate_cargo_lock step in the sdist build pipeline to reconcile lockfiles after workspace-member stripping.
src/module_writer/virtual_writer.rs	Adds helpers to materialize tracked sdist entries to disk and replace a tracked file’s bytes in-memory.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

[messense]

Thanks for the PR — the problem is real and reconciling the lockfile against the rewritten manifests is the right general approach. A few things need to change before this can merge though:

1. cargo generate-lockfile re-resolves everything to latest

Per the cargo docs, if the lockfile already exists it "will be rebuilt with the latest available version of every package" — it's effectively a full cargo update. So this doesn't just prune the stale entries: every third-party pin in the sdist's Cargo.lock silently floats to whatever is newest at sdist-build time. That breaks the reproducibility guarantee shipping a lockfile is meant to provide, contradicts a user-supplied --locked, and makes sdists non-reproducible day to day.

Please use cargo update --workspace instead — it conservatively preserves existing pins while re-resolving the graph, which drops the unreachable entries. (Running plain cargo metadata without --frozen for its minimal lockfile sync would also work.)

2. Trigger condition is too coarse

workspace_members.len() > 1 fires even when no member is actually stripped (all siblings are path deps that stay in the sdist). Combined with point 1, that rewrites previously-correct lockfiles. The rewrite code in cargo_toml_rewrite.rs already knows which members were dropped — plumbing that through (or checking whether the lockfile references packages absent from the sdist) would make this a no-op in the common case.

3. Offline / cargo config

This adds a hard network dependency to sdist builds for multi-member workspaces. At minimum, propagate ctx.project.cargo_options.offline as --offline. Also note the temp dir has no .cargo/config.toml, so source replacement / private registries won't be visible to the regeneration run — worth a comment, and possibly degrading to a warning + original lockfile on failure rather than failing the whole build.

Smaller points

• Pass --manifest-path explicitly instead of relying on current_dir + cargo's upward search (matches cargo_package_file_list in the same file).
• Missing space in the error message: `{}`(exit status: .
• Test: please add an assertion that a surviving pinned version is preserved (e.g. cargo update --precise something in the original lockfile, then compare) — that's the test that distinguishes "pruned" from "re-resolved", and it would have caught point 1. Asserting devtool/rand are absent from the regenerated lockfile would also be more direct than relying only on --frozen's exit status.

The VirtualWriter helpers themselves look good — replace_bytes preserving entry metadata and materialize_to reusing default_permission are both right.

[ckhordiasma]

@messense thanks for the review comments, I believe I have addressed them in the most recent commits.

(I'm seeing a CI failure that doesn't appear to be related to changes in this PR, maybe it's a flake? - not sure how to rerun checks)