Developing against external packages (including ones shared with Servo) and pulling in changes as needed can be an easier process than you expect, and the alternatives (forking or syncing) have much more serious consequences.
The basic idea is that you work with shared dependencies from crates.io or github under normal circumstances. If you find you need to make a quick change to a dependency to keep moving, you can fork that dependency on Github and use your local changes instead. At the same time, you submit the changes upstream as a pull request, and revert back to using the shared dependencies once they have been accepted. Since Gecko intends to, at minimum, share dependencies with Servo, this strategy should be the most seamless. That said, Servo has blazed a trail as one of the first Rust projects with a huge tree of dependencies, and uncovered some weaknesses in Cargo as a result. At Mozlando, we had a great conversation with the Servo team about how to help them manage upstream dependencies better. --- The main improvement that we plan to make to Cargo as a result of that conversation is *temporary overrides*. **Temporary overrides are an important part of the design of a package manager like Cargo** (Bundler, the package manager I worked on in the Ruby ecosystem, has support for temporary overrides). Let me outline how I envision that working in Cargo. --- Workflow (using Servo as an example) When a project discovers that it needs to make a temporary patch to an upstream dependency, it forks the project on Github. Next, it goes into the top-level `Cargo.toml` for their project and enters the override: ``` [[overrides.simd]] version = "*" git = "https://github.com/servo/simd"; ``` This means that any version of the `simd` crate used by Servo (directly or indirectly) will be overridden by the version supplied by `servo/simd`. This applies to crates from crates.io as well as other git crates. Next, Servo would submit a pull request to the original git repository that they have forked. Once the original owner has accepted the pull request, Servo can remove the override. Alternately, if the crate in question is owned by Servo (`servo/rust-freetype` for example), Servo can create a branch in `servo/rust-freetype` and use those changes using the same override mechanism: ``` [[overrides.rust-freetype]] version = "*" branch = "bugfix-3561" ``` I would also like to make this workflow nice from the command line, with `cargo override` or something similar. -- Yehuda > On Thu, Dec 17, 2015 at 3:04 PM, Valentin Gosu <valentin.g...@gmail.com> > wrote: > > > Hi folks, > > > > I just wanted to share some notes on using Cargo in Gecko. One of the > > requirements was vendoring packages in tree. It turns out I was able to do > > that with a .cargo/config file in the scope of the rust directory, which > > defines the paths for dependencies, and [http] timeout = 0, which prevents > > downloading any resources from crates.io. [1] > > Better support for this use case would be welcome, such as making sure no > > network connections are made (the index still gets refreshed), but this is > > good enough for what we need at the moment. > > > > I'm not sure if we've agreed to have a top level directory for all of the > > rust crates, but I think it makes sense. It allows for easier sharing of > > crates (between necko and media for example). > > From what I understand servo's mach has a command for two-way sync between > > web-platform-tests and upstream. This would be a nice feature for cargo, as > > most of our dependencies would come from crates.io. So identifying the > > upstream repo, and doing a diff would be super awesome - probably for other > > projects as well. > > > > I'll probably have more to share once/if I manage to use cargo withing > > Gecko's build system. > > > > Thanks! > > > > [1] https://github.com/rust-lang/cargo/issues/1926 > > _______________________________________________ > > dev-servo mailing list > > dev-servo@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-servo > > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
