On Mon, Dec 21, 2015 at 1:52 PM, <wyc...@gmail.com> wrote: > 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. >
I don't think this is going to fly in Gecko, unfortunately. Gecko is a monolithic repo, and everything needs to be vendored in-tree (a non-negotiable requirement from the build peers). This means that we'll already need an automated process for pulling in updates to the shared code, committing them, and running them through CI. The only remaining question, then, is whether we allow Gecko hackers to commit directly (with appropriate review) to the vendored code, or whether we require them hack on a local clone of the upstream. Gecko hackers expect to be able to easily make atomic changesets that span modules. They want to make a series of changsets that is, say, 15-deep and spanning multiple programming languages, interactively reorder those commits, bisect them, etc. They may grudgingly put up with barriers to that workflow for something self-contained and infrequently-touched (like the url parser), but requiring them to make a github fork to hack on the style system will likely meet insurmountable opposition. So of the aforementioned options, I'm pretty sure that only the first is workable. The two ways to implement that are with tooling for automatic upstreaming, or forking Servo. So I sure hope that we can figure out the tooling. ;-) bholley > 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 > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
