Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement top-level overrides #2385

Merged
merged 1 commit into from
Apr 7, 2016

Commits on Mar 25, 2016

  1. Implement top-level overrides

    This commit is an implementation of top-level overrides to be encoded into the
    manifest itself directly. This style of override is distinct from the existing
    `paths` support in `.cargo/config` in two important ways:
    
    * Top level overrides are intended to be checked in and shared amongst all
      developers of a project.
    * Top level overrides are reflected in `Cargo.lock`.
    
    The second point is crucially important here as it will ensure that an override
    on one machine behaves the same as an override on another machine. This solves
    many long-standing problems with `paths`-based overrides which suffer from some
    level of nondeterminism as they're not encoded.
    
    From a syntactical point of view, an override looks like:
    
    ```toml
    [replace]
    "libc:0.2.0" = { git = 'https://github.com/my-username/libc', branch = '0.2-fork' }
    ```
    
    This declaration indicates that whenever resolution would otherwise encounter
    the `libc` package version 0.2.0 from crates.io, it should instead replace it
    with the custom git dependency on a specific branch.
    
    The key "libc:0.2.0" here is actually a package id specification which will
    allow selecting various components of a graph. For example the same named
    package coming from two distinct locations can be selected against, as well as
    multiple versions of one crate in a dependency graph. The replacement dependency
    has the same syntax as the `[dependencies]` section of Cargo.toml.
    
    One of the major uses of this syntax will be, for example, using a temporary
    fork of a crate while the changes are pushed upstream to the original repo. This
    will avoid the need to change the intermediate projects immediately, and over
    time once fixes have landed upstream the `[replace]` section in a `Cargo.toml`
    can be removed.
    
    There are also two crucial restrictions on overrides.
    
    * A crate with the name `foo` can only get overridden with packages also of
      the name `foo`.
    * A crate can only get overridden with a crate of the exact same version.
    
    A consequence of these restrictions is that crates.io cannot be used to replace
    anything from crates.io. There's only one version of something on crates.io, so
    there's nothing else to replace it with (name/version are a unique key).
    
    Closes rust-lang#942
    alexcrichton committed Mar 25, 2016
    Configuration menu
    Copy the full SHA
    54d738b View commit details
    Browse the repository at this point in the history