On Mon, Feb 27, 2017 at 12:10 AM, Bobby Holley <[email protected]> wrote: > Can you elaborate on what goes wrong here? This worked for ted's experiment > mentioned upthread, and for me on at least one occasion in > https://hg.mozilla.org/try/rev/18dc070e0308 (permalink: > https://pastebin.mozilla.org/8980438 ) > > You'll need to |cargo update| after adding the replace in Cargo.toml to > update Cargo.lock.
Thanks. I failed to do that yesterday. When I do that, Cargo complains about not finding the encoding-index-foo crates in subdirectories of encoding. Replacement in gkrust's Cargo.toml doesn't work. So then I go and edit encoding's Cargo.toml to point it to the right place. Then Cargo complains about those crates not finding encoding_index_tests. So then I edit their Cargo.tomls to point to the test crate. Then cargo update passes. But then I do ./mach build and Cargo complains about the checksums not matching because I edited the Cargo.tomls under the crates that I thought I was changing from "locally-stored crates.io crate" status to "local replacement" status. The I remove the checksum file. The cargo complains about not finding the checksum file. I find this level of difficulty (self-inflicted quasi-Tivoization practically) an unreasonable impediment to practicing trivial Software Freedom with respect to the vendored crates. > This is basically the right way to do it, rather than editing the checksums. > [replace] tells the Cargo machinery that the vendored code is its own > snowflake, rather than just a cache of what's on crates.io. Doing otherwise > breaks cargo invariants. What are the invariants? Why do we need the invariants, when can do without impediments like these for e.g. the vendored copy of ICU? What badness would arise from patching Cargo to ignore the .cargo-checksum.json files? On Mon, Feb 27, 2017 at 1:23 AM, Xidorn Quan <[email protected]> wrote: > This workflow should really be automated via a mach command. Filed bug > 1342815 [1] for that. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1342815 Thank you. I think it should be possible to stick a diagnostic println!() or panic!() in the vendored code with zero or minimal ceremony. -- Henri Sivonen [email protected] https://hsivonen.fi/ _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
