cargo/tests/testsuite/registry.rs

1883 lines
42 KiB
Rust
Raw Normal View History

use std::fs::{self, File};
use std::io::prelude::*;
2018-12-06 19:17:36 +00:00
use crate::support::cargo_process;
use crate::support::git;
use crate::support::paths::{self, CargoPathExt};
use crate::support::registry::{self, registry_path, registry_url, Dependency, Package};
2018-12-06 19:17:36 +00:00
use crate::support::{basic_manifest, project};
2018-12-08 11:19:47 +00:00
use cargo::util::paths::remove_dir_all;
#[test]
fn simple() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = ">= 0.0.0"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("bar", "0.0.1").publish();
p.cargo("build")
.with_stderr(&format!(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `{reg}` index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] bar v0.0.1 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] bar v0.0.1
[COMPILING] foo v0.0.1 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
reg = registry_path().to_str().unwrap()
2018-12-08 11:19:47 +00:00
))
.run();
2014-09-09 14:23:09 +00:00
p.cargo("clean").run();
2014-09-09 14:23:09 +00:00
// Don't download a second time
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] bar v0.0.1
[COMPILING] foo v0.0.1 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
2014-09-09 14:23:09 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn deps() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = ">= 0.0.0"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("baz", "0.0.1").publish();
Package::new("bar", "0.0.1").dep("baz", "*").publish();
p.cargo("build")
.with_stderr(&format!(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `{reg}` index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] [..] v0.0.1 (registry `[ROOT][..]`)
[DOWNLOADED] [..] v0.0.1 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] baz v0.0.1
[COMPILING] bar v0.0.1
[COMPILING] foo v0.0.1 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
reg = registry_path().to_str().unwrap()
2018-12-08 11:19:47 +00:00
))
.run();
}
#[test]
fn nonexistent() {
Package::new("init", "0.0.1").publish();
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
nonexistent = ">= 0.0.0"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
p.cargo("build")
.with_status(101)
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] [..] index
2018-02-07 16:51:40 +00:00
error: no matching package named `nonexistent` found
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
location searched: registry [..]
2018-02-07 16:51:40 +00:00
required by package `foo v0.0.1 ([..])`
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
2018-07-09 22:02:46 +00:00
#[test]
fn wrong_case() {
Package::new("init", "0.0.1").publish();
let p = project()
2018-07-09 22:02:46 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
Init = ">= 0.0.0"
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
2018-07-09 22:02:46 +00:00
.build();
// #5678 to make this work
p.cargo("build")
.with_status(101)
.with_stderr(
2018-07-09 22:02:46 +00:00
"\
[UPDATING] [..] index
2018-07-09 22:02:46 +00:00
error: no matching package named `Init` found
location searched: registry [..]
did you mean: init
2018-07-09 22:02:46 +00:00
required by package `foo v0.0.1 ([..])`
",
2018-12-08 11:19:47 +00:00
)
.run();
2018-07-09 22:02:46 +00:00
}
#[test]
fn mis_hyphenated() {
Package::new("mis-hyphenated", "0.0.1").publish();
let p = project()
2018-07-09 22:02:46 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
mis_hyphenated = ">= 0.0.0"
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
2018-07-09 22:02:46 +00:00
.build();
// #2775 to make this work
p.cargo("build")
.with_status(101)
.with_stderr(
2018-07-09 22:02:46 +00:00
"\
[UPDATING] [..] index
2018-07-09 22:02:46 +00:00
error: no matching package named `mis_hyphenated` found
location searched: registry [..]
did you mean: mis-hyphenated
2018-07-09 22:02:46 +00:00
required by package `foo v0.0.1 ([..])`
",
2018-12-08 11:19:47 +00:00
)
.run();
2018-07-09 22:02:46 +00:00
}
#[test]
fn wrong_version() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
foo = ">= 1.0.0"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("foo", "0.0.1").publish();
Package::new("foo", "0.0.2").publish();
p.cargo("build")
.with_status(101)
.with_stderr_contains(
2018-03-14 15:17:44 +00:00
"\
error: failed to select a version for the requirement `foo = \">= 1.0.0\"`
candidate versions found which didn't match: 0.0.2, 0.0.1
location searched: `[..]` index (which is replacing registry `[..]`)
2018-02-07 16:51:40 +00:00
required by package `foo v0.0.1 ([..])`
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
Package::new("foo", "0.0.3").publish();
Package::new("foo", "0.0.4").publish();
p.cargo("build")
.with_status(101)
.with_stderr_contains(
2018-03-14 15:17:44 +00:00
"\
error: failed to select a version for the requirement `foo = \">= 1.0.0\"`
candidate versions found which didn't match: 0.0.4, 0.0.3, 0.0.2, ...
location searched: `[..]` index (which is replacing registry `[..]`)
2018-02-07 16:51:40 +00:00
required by package `foo v0.0.1 ([..])`
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn bad_cksum() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bad-cksum = ">= 0.0.0"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
let pkg = Package::new("bad-cksum", "0.0.1");
pkg.publish();
t!(File::create(&pkg.archive_dst()));
p.cargo("build -v")
.with_status(101)
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] [..] index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] bad-cksum [..]
[ERROR] failed to download replaced source registry `https://[..]`
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
Caused by:
failed to verify the checksum of `bad-cksum v0.0.1 (registry `[ROOT][..]`)`
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn update_registry() {
Package::new("init", "0.0.1").publish();
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
notyet = ">= 0.0.0"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
p.cargo("build")
.with_status(101)
.with_stderr_contains(
2018-03-14 15:17:44 +00:00
"\
2018-02-07 16:51:40 +00:00
error: no matching package named `notyet` found
location searched: registry `[..]`
required by package `foo v0.0.1 ([..])`
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
Package::new("notyet", "0.0.1").publish();
p.cargo("build")
.with_stderr(format!(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `{reg}` index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] notyet v0.0.1 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] notyet v0.0.1
[COMPILING] foo v0.0.1 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
reg = registry_path().to_str().unwrap()
2018-12-08 11:19:47 +00:00
))
.run();
}
#[test]
fn package_with_path_deps() {
Package::new("init", "0.0.1").publish();
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
license = "MIT"
description = "foo"
repository = "bar"
[dependencies.notyet]
version = "0.0.1"
path = "notyet"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
2018-07-24 22:35:01 +00:00
.file("notyet/Cargo.toml", &basic_manifest("notyet", "0.0.1"))
.file("notyet/src/lib.rs", "")
.build();
p.cargo("package -v")
.with_status(101)
.with_stderr_contains(
2018-03-14 15:17:44 +00:00
"\
[ERROR] failed to verify package tarball
Caused by:
2018-02-07 16:51:40 +00:00
no matching package named `notyet` found
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
location searched: registry [..]
2018-02-07 16:51:40 +00:00
required by package `foo v0.0.1 ([..])`
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
Package::new("notyet", "0.0.1").publish();
p.cargo("package")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[PACKAGING] foo v0.0.1 ([CWD])
[VERIFYING] foo v0.0.1 ([CWD])
[UPDATING] `[..]` index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] notyet v0.0.1 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] notyet v0.0.1
[COMPILING] foo v0.0.1 ([CWD][..])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
Integrate the lockfile and registry-based deps This commit radically changes the approach of how lockfiles are handled in the package registry and how resolve interacts with it. Previously "using a lockfile" entailed just adding all of the precise sources to the registry and relying on them not being updated to remain locked. This strategy does not work out well for the registry, however, as one source can provide many many packages and it may need to be updated for other reasons. This new strategy is to rewrite instances of `Summary` in an on-demand fashion to mention locked versions and sources wherever possible. This will ensure that any relevant `Dependency` will end up having an exact version requirement as well as a precise source to originate from (if possible). This rewriting is performed in a few locations: 1. The top-level package has its dependencies rewritten to their precise variants if the dependency still matches the precise variant. This covers the case where a dependency was updated the the lockfile now needs to be updated. 2. Any `Summary` returned from the package registry which matches a locked `PackageId` will unconditionally have all of its dependencies rewritten to their precise variants. This is done because any previously locked package must remain locked during resolution. 3. Any `Summary` which points at a package which was not previously locked still has its dependencies modified to point at any matching locked package. This is done to ensure that updates are as conservative as possible. There are still two outstanding problems with lockfiles and the registry which this commit does not attempt to solve: * Yanked versions are not respected * The registry is still unconditionally updated on all compiles.
2014-10-23 17:38:44 +00:00
#[test]
fn lockfile_locks() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Integrate the lockfile and registry-based deps This commit radically changes the approach of how lockfiles are handled in the package registry and how resolve interacts with it. Previously "using a lockfile" entailed just adding all of the precise sources to the registry and relying on them not being updated to remain locked. This strategy does not work out well for the registry, however, as one source can provide many many packages and it may need to be updated for other reasons. This new strategy is to rewrite instances of `Summary` in an on-demand fashion to mention locked versions and sources wherever possible. This will ensure that any relevant `Dependency` will end up having an exact version requirement as well as a precise source to originate from (if possible). This rewriting is performed in a few locations: 1. The top-level package has its dependencies rewritten to their precise variants if the dependency still matches the precise variant. This covers the case where a dependency was updated the the lockfile now needs to be updated. 2. Any `Summary` returned from the package registry which matches a locked `PackageId` will unconditionally have all of its dependencies rewritten to their precise variants. This is done because any previously locked package must remain locked during resolution. 3. Any `Summary` which points at a package which was not previously locked still has its dependencies modified to point at any matching locked package. This is done to ensure that updates are as conservative as possible. There are still two outstanding problems with lockfiles and the registry which this commit does not attempt to solve: * Yanked versions are not respected * The registry is still unconditionally updated on all compiles.
2014-10-23 17:38:44 +00:00
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Integrate the lockfile and registry-based deps This commit radically changes the approach of how lockfiles are handled in the package registry and how resolve interacts with it. Previously "using a lockfile" entailed just adding all of the precise sources to the registry and relying on them not being updated to remain locked. This strategy does not work out well for the registry, however, as one source can provide many many packages and it may need to be updated for other reasons. This new strategy is to rewrite instances of `Summary` in an on-demand fashion to mention locked versions and sources wherever possible. This will ensure that any relevant `Dependency` will end up having an exact version requirement as well as a precise source to originate from (if possible). This rewriting is performed in a few locations: 1. The top-level package has its dependencies rewritten to their precise variants if the dependency still matches the precise variant. This covers the case where a dependency was updated the the lockfile now needs to be updated. 2. Any `Summary` returned from the package registry which matches a locked `PackageId` will unconditionally have all of its dependencies rewritten to their precise variants. This is done because any previously locked package must remain locked during resolution. 3. Any `Summary` which points at a package which was not previously locked still has its dependencies modified to point at any matching locked package. This is done to ensure that updates are as conservative as possible. There are still two outstanding problems with lockfiles and the registry which this commit does not attempt to solve: * Yanked versions are not respected * The registry is still unconditionally updated on all compiles.
2014-10-23 17:38:44 +00:00
Package::new("bar", "0.0.1").publish();
Integrate the lockfile and registry-based deps This commit radically changes the approach of how lockfiles are handled in the package registry and how resolve interacts with it. Previously "using a lockfile" entailed just adding all of the precise sources to the registry and relying on them not being updated to remain locked. This strategy does not work out well for the registry, however, as one source can provide many many packages and it may need to be updated for other reasons. This new strategy is to rewrite instances of `Summary` in an on-demand fashion to mention locked versions and sources wherever possible. This will ensure that any relevant `Dependency` will end up having an exact version requirement as well as a precise source to originate from (if possible). This rewriting is performed in a few locations: 1. The top-level package has its dependencies rewritten to their precise variants if the dependency still matches the precise variant. This covers the case where a dependency was updated the the lockfile now needs to be updated. 2. Any `Summary` returned from the package registry which matches a locked `PackageId` will unconditionally have all of its dependencies rewritten to their precise variants. This is done because any previously locked package must remain locked during resolution. 3. Any `Summary` which points at a package which was not previously locked still has its dependencies modified to point at any matching locked package. This is done to ensure that updates are as conservative as possible. There are still two outstanding problems with lockfiles and the registry which this commit does not attempt to solve: * Yanked versions are not respected * The registry is still unconditionally updated on all compiles.
2014-10-23 17:38:44 +00:00
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] bar v0.0.1 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] bar v0.0.1
[COMPILING] foo v0.0.1 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-12-08 11:19:47 +00:00
)
.run();
Integrate the lockfile and registry-based deps This commit radically changes the approach of how lockfiles are handled in the package registry and how resolve interacts with it. Previously "using a lockfile" entailed just adding all of the precise sources to the registry and relying on them not being updated to remain locked. This strategy does not work out well for the registry, however, as one source can provide many many packages and it may need to be updated for other reasons. This new strategy is to rewrite instances of `Summary` in an on-demand fashion to mention locked versions and sources wherever possible. This will ensure that any relevant `Dependency` will end up having an exact version requirement as well as a precise source to originate from (if possible). This rewriting is performed in a few locations: 1. The top-level package has its dependencies rewritten to their precise variants if the dependency still matches the precise variant. This covers the case where a dependency was updated the the lockfile now needs to be updated. 2. Any `Summary` returned from the package registry which matches a locked `PackageId` will unconditionally have all of its dependencies rewritten to their precise variants. This is done because any previously locked package must remain locked during resolution. 3. Any `Summary` which points at a package which was not previously locked still has its dependencies modified to point at any matching locked package. This is done to ensure that updates are as conservative as possible. There are still two outstanding problems with lockfiles and the registry which this commit does not attempt to solve: * Yanked versions are not respected * The registry is still unconditionally updated on all compiles.
2014-10-23 17:38:44 +00:00
p.root().move_into_the_past();
Package::new("bar", "0.0.2").publish();
Integrate the lockfile and registry-based deps This commit radically changes the approach of how lockfiles are handled in the package registry and how resolve interacts with it. Previously "using a lockfile" entailed just adding all of the precise sources to the registry and relying on them not being updated to remain locked. This strategy does not work out well for the registry, however, as one source can provide many many packages and it may need to be updated for other reasons. This new strategy is to rewrite instances of `Summary` in an on-demand fashion to mention locked versions and sources wherever possible. This will ensure that any relevant `Dependency` will end up having an exact version requirement as well as a precise source to originate from (if possible). This rewriting is performed in a few locations: 1. The top-level package has its dependencies rewritten to their precise variants if the dependency still matches the precise variant. This covers the case where a dependency was updated the the lockfile now needs to be updated. 2. Any `Summary` returned from the package registry which matches a locked `PackageId` will unconditionally have all of its dependencies rewritten to their precise variants. This is done because any previously locked package must remain locked during resolution. 3. Any `Summary` which points at a package which was not previously locked still has its dependencies modified to point at any matching locked package. This is done to ensure that updates are as conservative as possible. There are still two outstanding problems with lockfiles and the registry which this commit does not attempt to solve: * Yanked versions are not respected * The registry is still unconditionally updated on all compiles.
2014-10-23 17:38:44 +00:00
p.cargo("build").with_stdout("").run();
}
Integrate the lockfile and registry-based deps This commit radically changes the approach of how lockfiles are handled in the package registry and how resolve interacts with it. Previously "using a lockfile" entailed just adding all of the precise sources to the registry and relying on them not being updated to remain locked. This strategy does not work out well for the registry, however, as one source can provide many many packages and it may need to be updated for other reasons. This new strategy is to rewrite instances of `Summary` in an on-demand fashion to mention locked versions and sources wherever possible. This will ensure that any relevant `Dependency` will end up having an exact version requirement as well as a precise source to originate from (if possible). This rewriting is performed in a few locations: 1. The top-level package has its dependencies rewritten to their precise variants if the dependency still matches the precise variant. This covers the case where a dependency was updated the the lockfile now needs to be updated. 2. Any `Summary` returned from the package registry which matches a locked `PackageId` will unconditionally have all of its dependencies rewritten to their precise variants. This is done because any previously locked package must remain locked during resolution. 3. Any `Summary` which points at a package which was not previously locked still has its dependencies modified to point at any matching locked package. This is done to ensure that updates are as conservative as possible. There are still two outstanding problems with lockfiles and the registry which this commit does not attempt to solve: * Yanked versions are not respected * The registry is still unconditionally updated on all compiles.
2014-10-23 17:38:44 +00:00
#[test]
fn lockfile_locks_transitively() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Integrate the lockfile and registry-based deps This commit radically changes the approach of how lockfiles are handled in the package registry and how resolve interacts with it. Previously "using a lockfile" entailed just adding all of the precise sources to the registry and relying on them not being updated to remain locked. This strategy does not work out well for the registry, however, as one source can provide many many packages and it may need to be updated for other reasons. This new strategy is to rewrite instances of `Summary` in an on-demand fashion to mention locked versions and sources wherever possible. This will ensure that any relevant `Dependency` will end up having an exact version requirement as well as a precise source to originate from (if possible). This rewriting is performed in a few locations: 1. The top-level package has its dependencies rewritten to their precise variants if the dependency still matches the precise variant. This covers the case where a dependency was updated the the lockfile now needs to be updated. 2. Any `Summary` returned from the package registry which matches a locked `PackageId` will unconditionally have all of its dependencies rewritten to their precise variants. This is done because any previously locked package must remain locked during resolution. 3. Any `Summary` which points at a package which was not previously locked still has its dependencies modified to point at any matching locked package. This is done to ensure that updates are as conservative as possible. There are still two outstanding problems with lockfiles and the registry which this commit does not attempt to solve: * Yanked versions are not respected * The registry is still unconditionally updated on all compiles.
2014-10-23 17:38:44 +00:00
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Integrate the lockfile and registry-based deps This commit radically changes the approach of how lockfiles are handled in the package registry and how resolve interacts with it. Previously "using a lockfile" entailed just adding all of the precise sources to the registry and relying on them not being updated to remain locked. This strategy does not work out well for the registry, however, as one source can provide many many packages and it may need to be updated for other reasons. This new strategy is to rewrite instances of `Summary` in an on-demand fashion to mention locked versions and sources wherever possible. This will ensure that any relevant `Dependency` will end up having an exact version requirement as well as a precise source to originate from (if possible). This rewriting is performed in a few locations: 1. The top-level package has its dependencies rewritten to their precise variants if the dependency still matches the precise variant. This covers the case where a dependency was updated the the lockfile now needs to be updated. 2. Any `Summary` returned from the package registry which matches a locked `PackageId` will unconditionally have all of its dependencies rewritten to their precise variants. This is done because any previously locked package must remain locked during resolution. 3. Any `Summary` which points at a package which was not previously locked still has its dependencies modified to point at any matching locked package. This is done to ensure that updates are as conservative as possible. There are still two outstanding problems with lockfiles and the registry which this commit does not attempt to solve: * Yanked versions are not respected * The registry is still unconditionally updated on all compiles.
2014-10-23 17:38:44 +00:00
Package::new("baz", "0.0.1").publish();
Package::new("bar", "0.0.1").dep("baz", "*").publish();
Integrate the lockfile and registry-based deps This commit radically changes the approach of how lockfiles are handled in the package registry and how resolve interacts with it. Previously "using a lockfile" entailed just adding all of the precise sources to the registry and relying on them not being updated to remain locked. This strategy does not work out well for the registry, however, as one source can provide many many packages and it may need to be updated for other reasons. This new strategy is to rewrite instances of `Summary` in an on-demand fashion to mention locked versions and sources wherever possible. This will ensure that any relevant `Dependency` will end up having an exact version requirement as well as a precise source to originate from (if possible). This rewriting is performed in a few locations: 1. The top-level package has its dependencies rewritten to their precise variants if the dependency still matches the precise variant. This covers the case where a dependency was updated the the lockfile now needs to be updated. 2. Any `Summary` returned from the package registry which matches a locked `PackageId` will unconditionally have all of its dependencies rewritten to their precise variants. This is done because any previously locked package must remain locked during resolution. 3. Any `Summary` which points at a package which was not previously locked still has its dependencies modified to point at any matching locked package. This is done to ensure that updates are as conservative as possible. There are still two outstanding problems with lockfiles and the registry which this commit does not attempt to solve: * Yanked versions are not respected * The registry is still unconditionally updated on all compiles.
2014-10-23 17:38:44 +00:00
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] [..] v0.0.1 (registry `[ROOT][..]`)
[DOWNLOADED] [..] v0.0.1 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] baz v0.0.1
[COMPILING] bar v0.0.1
[COMPILING] foo v0.0.1 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-12-08 11:19:47 +00:00
)
.run();
Integrate the lockfile and registry-based deps This commit radically changes the approach of how lockfiles are handled in the package registry and how resolve interacts with it. Previously "using a lockfile" entailed just adding all of the precise sources to the registry and relying on them not being updated to remain locked. This strategy does not work out well for the registry, however, as one source can provide many many packages and it may need to be updated for other reasons. This new strategy is to rewrite instances of `Summary` in an on-demand fashion to mention locked versions and sources wherever possible. This will ensure that any relevant `Dependency` will end up having an exact version requirement as well as a precise source to originate from (if possible). This rewriting is performed in a few locations: 1. The top-level package has its dependencies rewritten to their precise variants if the dependency still matches the precise variant. This covers the case where a dependency was updated the the lockfile now needs to be updated. 2. Any `Summary` returned from the package registry which matches a locked `PackageId` will unconditionally have all of its dependencies rewritten to their precise variants. This is done because any previously locked package must remain locked during resolution. 3. Any `Summary` which points at a package which was not previously locked still has its dependencies modified to point at any matching locked package. This is done to ensure that updates are as conservative as possible. There are still two outstanding problems with lockfiles and the registry which this commit does not attempt to solve: * Yanked versions are not respected * The registry is still unconditionally updated on all compiles.
2014-10-23 17:38:44 +00:00
p.root().move_into_the_past();
Package::new("baz", "0.0.2").publish();
Package::new("bar", "0.0.2").dep("baz", "*").publish();
Integrate the lockfile and registry-based deps This commit radically changes the approach of how lockfiles are handled in the package registry and how resolve interacts with it. Previously "using a lockfile" entailed just adding all of the precise sources to the registry and relying on them not being updated to remain locked. This strategy does not work out well for the registry, however, as one source can provide many many packages and it may need to be updated for other reasons. This new strategy is to rewrite instances of `Summary` in an on-demand fashion to mention locked versions and sources wherever possible. This will ensure that any relevant `Dependency` will end up having an exact version requirement as well as a precise source to originate from (if possible). This rewriting is performed in a few locations: 1. The top-level package has its dependencies rewritten to their precise variants if the dependency still matches the precise variant. This covers the case where a dependency was updated the the lockfile now needs to be updated. 2. Any `Summary` returned from the package registry which matches a locked `PackageId` will unconditionally have all of its dependencies rewritten to their precise variants. This is done because any previously locked package must remain locked during resolution. 3. Any `Summary` which points at a package which was not previously locked still has its dependencies modified to point at any matching locked package. This is done to ensure that updates are as conservative as possible. There are still two outstanding problems with lockfiles and the registry which this commit does not attempt to solve: * Yanked versions are not respected * The registry is still unconditionally updated on all compiles.
2014-10-23 17:38:44 +00:00
p.cargo("build").with_stdout("").run();
}
#[test]
fn yanks_are_not_used() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("baz", "0.0.1").publish();
Package::new("baz", "0.0.2").yanked(true).publish();
Package::new("bar", "0.0.1").dep("baz", "*").publish();
2018-03-14 15:17:44 +00:00
Package::new("bar", "0.0.2")
.dep("baz", "*")
.yanked(true)
.publish();
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] [..] v0.0.1 (registry `[ROOT][..]`)
[DOWNLOADED] [..] v0.0.1 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] baz v0.0.1
[COMPILING] bar v0.0.1
[COMPILING] foo v0.0.1 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn relying_on_a_yank_is_bad() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("baz", "0.0.1").publish();
Package::new("baz", "0.0.2").yanked(true).publish();
Package::new("bar", "0.0.1").dep("baz", "=0.0.2").publish();
p.cargo("build")
.with_status(101)
.with_stderr_contains(
2018-03-14 15:17:44 +00:00
"\
error: failed to select a version for the requirement `baz = \"= 0.0.2\"`
candidate versions found which didn't match: 0.0.1
location searched: `[..]` index (which is replacing registry `[..]`)
2018-02-07 16:51:40 +00:00
required by package `bar v0.0.1`
... which is depended on by `foo [..]`
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn yanks_in_lockfiles_are_ok() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("bar", "0.0.1").publish();
p.cargo("build").run();
registry_path().join("3").rm_rf();
Package::new("bar", "0.0.1").yanked(true).publish();
p.cargo("build").with_stdout("").run();
p.cargo("update")
.with_status(101)
.with_stderr_contains(
2018-03-14 15:17:44 +00:00
"\
2018-02-07 16:51:40 +00:00
error: no matching package named `bar` found
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
location searched: registry [..]
2018-02-07 16:51:40 +00:00
required by package `foo v0.0.1 ([..])`
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn update_with_lockfile_if_packages_missing() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("bar", "0.0.1").publish();
p.cargo("build").run();
p.root().move_into_the_past();
paths::home().join(".cargo/registry").rm_rf();
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] bar v0.0.1 (registry `[ROOT][..]`)
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn update_lockfile() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
println!("0.0.1");
Package::new("bar", "0.0.1").publish();
p.cargo("build").run();
Package::new("bar", "0.0.2").publish();
Package::new("bar", "0.0.3").publish();
paths::home().join(".cargo/registry").rm_rf();
println!("0.0.2 update");
p.cargo("update -p bar --precise 0.0.2")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[UPDATING] bar v0.0.1 -> v0.0.2
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
println!("0.0.2 build");
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] [..] v0.0.2 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] bar v0.0.2
[COMPILING] foo v0.0.1 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-12-08 11:19:47 +00:00
)
.run();
println!("0.0.3 update");
p.cargo("update -p bar")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[UPDATING] bar v0.0.2 -> v0.0.3
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
println!("0.0.3 build");
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] [..] v0.0.3 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] bar v0.0.3
[COMPILING] foo v0.0.1 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-12-08 11:19:47 +00:00
)
.run();
2018-03-14 15:17:44 +00:00
println!("new dependencies update");
Package::new("bar", "0.0.4").dep("spam", "0.2.5").publish();
Package::new("spam", "0.2.5").publish();
p.cargo("update -p bar")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[UPDATING] bar v0.0.3 -> v0.0.4
[ADDING] spam v0.2.5
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
2018-03-14 15:17:44 +00:00
println!("new dependencies update");
Package::new("bar", "0.0.5").publish();
p.cargo("update -p bar")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[UPDATING] bar v0.0.4 -> v0.0.5
[REMOVING] spam v0.2.5
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
2018-03-14 15:17:44 +00:00
fn update_offline() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
p.cargo("update -Zoffline")
.masquerade_as_nightly_cargo()
.with_status(101)
.with_stderr("error: you can't update in the offline mode[..]")
.run();
}
#[test]
fn dev_dependency_not_used() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
bar = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("baz", "0.0.1").publish();
Package::new("bar", "0.0.1").dev_dep("baz", "*").publish();
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] [..] v0.0.1 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] bar v0.0.1
[COMPILING] foo v0.0.1 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn login_with_no_cargo_dir() {
2018-12-20 01:40:01 +00:00
// Create a config in the root directory because `login` requires the
// index to be updated, and we don't want to hit crates.io.
registry::init();
fs::rename(paths::home().join(".cargo"), paths::root().join(".cargo")).unwrap();
paths::home().rm_rf();
cargo_process("login foo -v").run();
2018-12-20 01:40:01 +00:00
let credentials = fs::read_to_string(paths::home().join(".cargo/credentials")).unwrap();
assert_eq!(credentials, "[registry]\ntoken = \"foo\"\n");
}
2016-08-16 20:51:08 +00:00
#[test]
fn login_with_differently_sized_token() {
2018-12-20 01:40:01 +00:00
// Verify that the configuration file gets properly truncated.
registry::init();
let credentials = paths::home().join(".cargo/credentials");
fs::remove_file(&credentials).unwrap();
cargo_process("login lmaolmaolmao -v").run();
cargo_process("login lmao -v").run();
cargo_process("login lmaolmaolmao -v").run();
let credentials = fs::read_to_string(&credentials).unwrap();
2018-12-20 01:40:01 +00:00
assert_eq!(credentials, "[registry]\ntoken = \"lmaolmaolmao\"\n");
2016-08-16 20:51:08 +00:00
}
#[test]
fn bad_license_file() {
Package::new("foo", "1.0.0").publish();
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
license-file = "foo"
description = "bar"
repository = "baz"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
p.cargo("publish -v --index")
.arg(registry_url().to_string())
.with_status(101)
.with_stderr_contains("[ERROR] the license file `foo` does not exist")
.run();
}
#[test]
fn updating_a_dep() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies.a]
path = "a"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
2018-03-14 15:17:44 +00:00
.file(
"a/Cargo.toml",
r#"
[project]
name = "a"
version = "0.0.1"
authors = []
[dependencies]
bar = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("a/src/lib.rs", "")
.build();
Package::new("bar", "0.0.1").publish();
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] bar v0.0.1 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] bar v0.0.1
[COMPILING] a v0.0.1 ([CWD]/a)
[COMPILING] foo v0.0.1 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-12-08 11:19:47 +00:00
)
.run();
2018-03-14 15:17:44 +00:00
t!(t!(File::create(&p.root().join("a/Cargo.toml"))).write_all(
br#"
[project]
name = "a"
version = "0.0.1"
authors = []
[dependencies]
bar = "0.1.0"
2018-03-14 15:17:44 +00:00
"#
));
Package::new("bar", "0.1.0").publish();
println!("second");
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] bar v0.1.0 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] bar v0.1.0
[COMPILING] a v0.0.1 ([CWD]/a)
[COMPILING] foo v0.0.1 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn git_and_registry_dep() {
let b = git::repo(&paths::root().join("b"))
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "b"
version = "0.0.1"
authors = []
[dependencies]
a = "0.0.1"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
.build();
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
&format!(
r#"
[project]
name = "foo"
version = "0.0.1"
authors = []
[dependencies]
a = "0.0.1"
[dependencies.b]
git = '{}'
2018-03-14 15:17:44 +00:00
"#,
b.url()
),
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("a", "0.0.1").publish();
p.root().move_into_the_past();
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] [..]
[UPDATING] [..]
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] a v0.0.1 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] a v0.0.1
[COMPILING] b v0.0.1 ([..])
[COMPILING] foo v0.0.1 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-12-08 11:19:47 +00:00
)
.run();
p.root().move_into_the_past();
println!("second");
p.cargo("build").with_stdout("").run();
}
#[test]
fn update_publish_then_update() {
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
// First generate a Cargo.lock and a clone of the registry index at the
// "head" of the current registry.
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.5.0"
authors = []
[dependencies]
a = "0.1.0"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("a", "0.1.0").publish();
p.cargo("build").run();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
// Next, publish a new package and back up the copy of the registry we just
// created.
Package::new("a", "0.1.1").publish();
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
let registry = paths::home().join(".cargo/registry");
let backup = paths::root().join("registry-backup");
t!(fs::rename(&registry, &backup));
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
// Generate a Cargo.lock with the newer version, and then move the old copy
// of the registry back into place.
let p2 = project()
.at("foo2")
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
[project]
name = "foo"
version = "0.5.0"
authors = []
[dependencies]
a = "0.1.1"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
p2.cargo("build").run();
registry.rm_rf();
t!(fs::rename(&backup, &registry));
2018-03-14 15:17:44 +00:00
t!(fs::rename(
p2.root().join("Cargo.lock"),
p.root().join("Cargo.lock")
));
Add sha256 checksums to the lockfile This commit changes how lock files are encoded by checksums for each package in the lockfile to the `[metadata]` section. The previous commit implemented the ability to redirect sources, but the core assumption there was that a package coming from two different locations was always the same. An inevitable case, however, is that a source gets corrupted or, worse, ships a modified version of a crate to introduce instability between two "mirrors". The purpose of adding checksums will be to resolve this discrepancy. Each crate coming from crates.io will now record its sha256 checksum in the lock file. When a lock file already exists, the new checksum for a crate will be checked against it, and if they differ compilation will be aborted. Currently only registry crates will have sha256 checksums listed, all other sources do not have checksums at this time. The astute may notice that if the lock file format is changing, then a lock file generated by a newer Cargo might be mangled by an older Cargo. In anticipation of this, however, all Cargo versions published support a `[metadata]` section of the lock file which is transparently carried forward if encountered. This means that older Cargos compiling with a newer lock file will not verify checksums in the lock file, but they will carry forward the checksum information and prevent it from being removed. There are, however, a few situations where problems may still arise: 1. If an older Cargo takes a newer lockfile (with checksums) and updates it with a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then the `[metadata]` section will not be updated appropriately. This modification would require a newer Cargo to come in and update the checksums for such a modification. 2. Today Cargo can only calculate checksums for registry sources, but we may eventually want to support other sources like git (or just straight-up path sources). If future Cargo implements support for this sort of checksum, then it's the same problem as above where older Cargos will not know how to keep the checksum in sync
2016-02-03 19:04:07 +00:00
// Finally, build the first project again (with our newer Cargo.lock) which
// should force an update of the old registry, download the new crate, and
// then build everything again.
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] [..]
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] a v0.1.1 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] a v0.1.1
[COMPILING] foo v0.5.0 ([CWD])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn fetch_downloads() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.5.0"
authors = []
[dependencies]
a = "0.1.0"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("a", "0.1.0").publish();
p.cargo("fetch")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] a v0.1.0 (registry [..])
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn update_transitive_dependency() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.5.0"
authors = []
[dependencies]
a = "0.1.0"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("a", "0.1.0").dep("b", "*").publish();
Package::new("b", "0.1.0").publish();
p.cargo("fetch").run();
Package::new("b", "0.1.1").publish();
p.cargo("update -pb")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[UPDATING] b v0.1.0 -> v0.1.1
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] b v0.1.1 (registry `[ROOT][..]`)
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] b v0.1.1
[COMPILING] a v0.1.0
[COMPILING] foo v0.5.0 ([..])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn update_backtracking_ok() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.5.0"
authors = []
[dependencies]
webdriver = "0.1"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
2018-03-14 15:17:44 +00:00
Package::new("webdriver", "0.1.0")
.dep("hyper", "0.6")
.publish();
Package::new("hyper", "0.6.5")
.dep("openssl", "0.1")
.dep("cookie", "0.1")
.publish();
Package::new("cookie", "0.1.0")
.dep("openssl", "0.1")
.publish();
Package::new("openssl", "0.1.0").publish();
p.cargo("generate-lockfile").run();
Package::new("openssl", "0.1.1").publish();
2018-03-14 15:17:44 +00:00
Package::new("hyper", "0.6.6")
.dep("openssl", "0.1.1")
.dep("cookie", "0.1.0")
.publish();
p.cargo("update -p hyper")
.with_stderr(
"\
[UPDATING] `[..]` index
[UPDATING] hyper v0.6.5 -> v0.6.6
[UPDATING] openssl v0.1.0 -> v0.1.1
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn update_multiple_packages() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.5.0"
authors = []
[dependencies]
a = "*"
b = "*"
c = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("a", "0.1.0").publish();
Package::new("b", "0.1.0").publish();
Package::new("c", "0.1.0").publish();
p.cargo("fetch").run();
Package::new("a", "0.1.1").publish();
Package::new("b", "0.1.1").publish();
Package::new("c", "0.1.1").publish();
p.cargo("update -pa -pb")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[UPDATING] a v0.1.0 -> v0.1.1
[UPDATING] b v0.1.0 -> v0.1.1
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
p.cargo("update -pb -pc")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[UPDATING] c v0.1.0 -> v0.1.1
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
p.cargo("build")
2018-09-14 20:33:18 +00:00
.with_stderr_contains("[DOWNLOADED] a v0.1.1 (registry `[ROOT][..]`)")
.with_stderr_contains("[DOWNLOADED] b v0.1.1 (registry `[ROOT][..]`)")
.with_stderr_contains("[DOWNLOADED] c v0.1.1 (registry `[ROOT][..]`)")
.with_stderr_contains("[COMPILING] a v0.1.1")
.with_stderr_contains("[COMPILING] b v0.1.1")
.with_stderr_contains("[COMPILING] c v0.1.1")
.with_stderr_contains("[COMPILING] foo v0.5.0 ([..])")
.run();
}
#[test]
fn bundled_crate_in_registry() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "foo"
version = "0.5.0"
authors = []
[dependencies]
bar = "0.1"
baz = "0.1"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("bar", "0.1.0").publish();
Package::new("baz", "0.1.0")
.dep("bar", "0.1.0")
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[package]
name = "baz"
version = "0.1.0"
authors = []
[dependencies]
bar = { path = "bar", version = "0.1.0" }
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
2018-07-24 22:35:01 +00:00
.file("bar/Cargo.toml", &basic_manifest("bar", "0.1.0"))
.file("bar/src/lib.rs", "")
.publish();
p.cargo("run").run();
}
#[test]
fn update_same_prefix_oh_my_how_was_this_a_bug() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "ugh"
version = "0.5.0"
authors = []
[dependencies]
foo = "0.1"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("foobar", "0.2.0").publish();
Package::new("foo", "0.1.0")
.dep("foobar", "0.2.0")
.publish();
p.cargo("generate-lockfile").run();
p.cargo("update -pfoobar --precise=0.2.0").run();
}
2016-02-01 22:02:23 +00:00
#[test]
fn use_semver() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "bar"
version = "0.5.0"
authors = []
2016-02-01 22:02:23 +00:00
[dependencies]
foo = "1.2.3-alpha.0"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
2016-02-01 22:02:23 +00:00
Package::new("foo", "1.2.3-alpha.0").publish();
2016-02-01 22:02:23 +00:00
p.cargo("build").run();
}
#[test]
fn only_download_relevant() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "bar"
version = "0.5.0"
authors = []
[target.foo.dependencies]
foo = "*"
[dev-dependencies]
bar = "*"
[dependencies]
baz = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("foo", "0.1.0").publish();
Package::new("bar", "0.1.0").publish();
Package::new("baz", "0.1.0").publish();
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] `[..]` index
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] baz v0.1.0 ([..])
Implement source redirection This commit implements a scheme for .cargo/config files where sources can be redirected to other sources. The purpose of this will be to override crates.io for a few use cases: * Replace it with a mirror site that is sync'd to crates.io * Replace it with a "directory source" or some other local source This major feature of this redirection, however, is that none of it is encoded into the lock file. If one source is redirected to another then it is assumed that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in both location). The lock file simply encodes the canonical soure (e.g. crates.io) rather than the replacement source. In the end this means that Cargo.lock files can be generated from any replacement source and shipped to other locations without the lockfile oscillating about where packages came from. Eventually this support will be extended to `Cargo.toml` itself (which will be encoded into the lock file), but that support is not implemented today. The syntax for what was implemented today looks like: # .cargo/config [source.my-awesome-registry] registry = 'https://example.com/path/to/index' [source.crates-io] replace-with = 'my-awesome-registry' Each source will have a canonical name and will be configured with the various keys underneath it (today just 'registry' and 'directory' will be accepted). The global `crates-io` source represents crates from the standard registry, and this can be replaced with other mirror sources. All tests have been modified to use this new infrastructure instead of the old `registry.index` configuration. This configuration is now also deprecated and will emit an unconditional warning about how it will no longer be used in the future. Finally, all subcommands now use this "source map" except for `cargo publish`, which will always publish to the default registry (in this case crates.io).
2016-02-03 18:54:07 +00:00
[COMPILING] baz v0.1.0
[COMPILING] bar v0.5.0 ([..])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn resolve_and_backtracking() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "bar"
version = "0.5.0"
authors = []
[dependencies]
foo = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("foo", "0.1.1")
2018-03-14 15:17:44 +00:00
.feature_dep("bar", "0.1", &["a", "b"])
.publish();
Package::new("foo", "0.1.0").publish();
p.cargo("build").run();
}
#[test]
fn upstream_warnings_on_extra_verbose() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "bar"
version = "0.5.0"
authors = []
[dependencies]
foo = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("foo", "0.1.0")
2018-03-14 15:17:44 +00:00
.file("src/lib.rs", "fn unused() {}")
.publish();
p.cargo("build -vv")
.with_stderr_contains("[..]warning: function is never used[..]")
.run();
}
Add flags to assert lock/cache behavior to Cargo If a lock file is generated and some equivalent of `cargo fetch` is run then Cargo shouldn't ever touch the network or modify `Cargo.lock` until any `Cargo.toml` later changes, but this often wants to be asserted in some build environments where it's a programmer error if Cargo attempts to access the network. The `--locked` flag added here will assert that `Cargo.lock` does not need to change to proceed. That is, if `Cargo.lock` would be modified (as it automatically is by default) this is turned into a hard error instead. This `--frozen` will not only assert that `Cargo.lock` doesn't change (the same behavior as `--locked`), but it will also will manually prevent Cargo from touching the network by ensuring that all network requests return an error. These flags can be used in environments where it is *expected* that no network access happens (or no lockfile changes happen) because it has been pre-arranged for Cargo to not happen. Examples of this include: * CI for projects want to pass `--locked` to ensure that `Cargo.lock` is up to date before changes are checked in. * Environments with vendored dependencies want to pass `--frozen` as touching the network indicates a programmer error that something wasn't vendored correctly. A crucial property of these two flags is that **they do not change the behavior of Cargo**. They are simply assertions at a few locations in Cargo to ensure that actions expected to not happen indeed don't happen. Some documentation has also been added to this effect. Closes #2111
2016-06-28 17:39:46 +00:00
#[test]
fn disallow_network() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Add flags to assert lock/cache behavior to Cargo If a lock file is generated and some equivalent of `cargo fetch` is run then Cargo shouldn't ever touch the network or modify `Cargo.lock` until any `Cargo.toml` later changes, but this often wants to be asserted in some build environments where it's a programmer error if Cargo attempts to access the network. The `--locked` flag added here will assert that `Cargo.lock` does not need to change to proceed. That is, if `Cargo.lock` would be modified (as it automatically is by default) this is turned into a hard error instead. This `--frozen` will not only assert that `Cargo.lock` doesn't change (the same behavior as `--locked`), but it will also will manually prevent Cargo from touching the network by ensuring that all network requests return an error. These flags can be used in environments where it is *expected* that no network access happens (or no lockfile changes happen) because it has been pre-arranged for Cargo to not happen. Examples of this include: * CI for projects want to pass `--locked` to ensure that `Cargo.lock` is up to date before changes are checked in. * Environments with vendored dependencies want to pass `--frozen` as touching the network indicates a programmer error that something wasn't vendored correctly. A crucial property of these two flags is that **they do not change the behavior of Cargo**. They are simply assertions at a few locations in Cargo to ensure that actions expected to not happen indeed don't happen. Some documentation has also been added to this effect. Closes #2111
2016-06-28 17:39:46 +00:00
[project]
name = "bar"
version = "0.5.0"
authors = []
[dependencies]
foo = "*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
Add flags to assert lock/cache behavior to Cargo If a lock file is generated and some equivalent of `cargo fetch` is run then Cargo shouldn't ever touch the network or modify `Cargo.lock` until any `Cargo.toml` later changes, but this often wants to be asserted in some build environments where it's a programmer error if Cargo attempts to access the network. The `--locked` flag added here will assert that `Cargo.lock` does not need to change to proceed. That is, if `Cargo.lock` would be modified (as it automatically is by default) this is turned into a hard error instead. This `--frozen` will not only assert that `Cargo.lock` doesn't change (the same behavior as `--locked`), but it will also will manually prevent Cargo from touching the network by ensuring that all network requests return an error. These flags can be used in environments where it is *expected* that no network access happens (or no lockfile changes happen) because it has been pre-arranged for Cargo to not happen. Examples of this include: * CI for projects want to pass `--locked` to ensure that `Cargo.lock` is up to date before changes are checked in. * Environments with vendored dependencies want to pass `--frozen` as touching the network indicates a programmer error that something wasn't vendored correctly. A crucial property of these two flags is that **they do not change the behavior of Cargo**. They are simply assertions at a few locations in Cargo to ensure that actions expected to not happen indeed don't happen. Some documentation has also been added to this effect. Closes #2111
2016-06-28 17:39:46 +00:00
p.cargo("build --frozen")
.with_status(101)
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
Add flags to assert lock/cache behavior to Cargo If a lock file is generated and some equivalent of `cargo fetch` is run then Cargo shouldn't ever touch the network or modify `Cargo.lock` until any `Cargo.toml` later changes, but this often wants to be asserted in some build environments where it's a programmer error if Cargo attempts to access the network. The `--locked` flag added here will assert that `Cargo.lock` does not need to change to proceed. That is, if `Cargo.lock` would be modified (as it automatically is by default) this is turned into a hard error instead. This `--frozen` will not only assert that `Cargo.lock` doesn't change (the same behavior as `--locked`), but it will also will manually prevent Cargo from touching the network by ensuring that all network requests return an error. These flags can be used in environments where it is *expected* that no network access happens (or no lockfile changes happen) because it has been pre-arranged for Cargo to not happen. Examples of this include: * CI for projects want to pass `--locked` to ensure that `Cargo.lock` is up to date before changes are checked in. * Environments with vendored dependencies want to pass `--frozen` as touching the network indicates a programmer error that something wasn't vendored correctly. A crucial property of these two flags is that **they do not change the behavior of Cargo**. They are simply assertions at a few locations in Cargo to ensure that actions expected to not happen indeed don't happen. Some documentation has also been added to this effect. Closes #2111
2016-06-28 17:39:46 +00:00
error: failed to load source for a dependency on `foo`
Caused by:
Unable to update registry [..]
Caused by:
attempting to make an HTTP request, but --frozen was specified
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
Add flags to assert lock/cache behavior to Cargo If a lock file is generated and some equivalent of `cargo fetch` is run then Cargo shouldn't ever touch the network or modify `Cargo.lock` until any `Cargo.toml` later changes, but this often wants to be asserted in some build environments where it's a programmer error if Cargo attempts to access the network. The `--locked` flag added here will assert that `Cargo.lock` does not need to change to proceed. That is, if `Cargo.lock` would be modified (as it automatically is by default) this is turned into a hard error instead. This `--frozen` will not only assert that `Cargo.lock` doesn't change (the same behavior as `--locked`), but it will also will manually prevent Cargo from touching the network by ensuring that all network requests return an error. These flags can be used in environments where it is *expected* that no network access happens (or no lockfile changes happen) because it has been pre-arranged for Cargo to not happen. Examples of this include: * CI for projects want to pass `--locked` to ensure that `Cargo.lock` is up to date before changes are checked in. * Environments with vendored dependencies want to pass `--frozen` as touching the network indicates a programmer error that something wasn't vendored correctly. A crucial property of these two flags is that **they do not change the behavior of Cargo**. They are simply assertions at a few locations in Cargo to ensure that actions expected to not happen indeed don't happen. Some documentation has also been added to this effect. Closes #2111
2016-06-28 17:39:46 +00:00
}
#[test]
fn add_dep_dont_update_registry() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "bar"
version = "0.5.0"
authors = []
[dependencies]
baz = { path = "baz" }
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
2018-03-14 15:17:44 +00:00
.file(
"baz/Cargo.toml",
r#"
[project]
name = "baz"
version = "0.5.0"
authors = []
[dependencies]
remote = "0.3"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("baz/src/lib.rs", "")
.build();
Package::new("remote", "0.3.4").publish();
p.cargo("build").run();
2018-03-14 15:17:44 +00:00
t!(t!(File::create(p.root().join("Cargo.toml"))).write_all(
br#"
[project]
name = "bar"
version = "0.5.0"
authors = []
[dependencies]
baz = { path = "baz" }
remote = "0.3"
2018-03-14 15:17:44 +00:00
"#
));
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[COMPILING] bar v0.5.0 ([..])
[FINISHED] [..]
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn bump_version_dont_update_registry() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "bar"
version = "0.5.0"
authors = []
[dependencies]
baz = { path = "baz" }
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
2018-03-14 15:17:44 +00:00
.file(
"baz/Cargo.toml",
r#"
[project]
name = "baz"
version = "0.5.0"
authors = []
[dependencies]
remote = "0.3"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("baz/src/lib.rs", "")
.build();
Package::new("remote", "0.3.4").publish();
p.cargo("build").run();
2018-03-14 15:17:44 +00:00
t!(t!(File::create(p.root().join("Cargo.toml"))).write_all(
br#"
[project]
name = "bar"
version = "0.6.0"
authors = []
[dependencies]
baz = { path = "baz" }
2018-03-14 15:17:44 +00:00
"#
));
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[COMPILING] bar v0.6.0 ([..])
[FINISHED] [..]
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
2016-10-07 19:43:48 +00:00
#[test]
fn old_version_req() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
2016-10-07 19:43:48 +00:00
[project]
name = "bar"
version = "0.5.0"
authors = []
[dependencies]
remote = "0.2*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
2016-10-07 19:43:48 +00:00
Package::new("remote", "0.2.0").publish();
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
2016-10-07 19:43:48 +00:00
warning: parsed version requirement `0.2*` is no longer valid
Previous versions of Cargo accepted this malformed requirement,
but it is being deprecated. This was found when parsing the manifest
of bar 0.5.0, and the correct version requirement is `0.2.*`.
This will soon become a hard error, so it's either recommended to
update to a fixed version or contact the upstream maintainer about
this warning.
warning: parsed version requirement `0.2*` is no longer valid
Previous versions of Cargo accepted this malformed requirement,
but it is being deprecated. This was found when parsing the manifest
of bar 0.5.0, and the correct version requirement is `0.2.*`.
This will soon become a hard error, so it's either recommended to
update to a fixed version or contact the upstream maintainer about
this warning.
[UPDATING] [..]
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] [..]
2016-10-07 19:43:48 +00:00
[COMPILING] [..]
[COMPILING] [..]
[FINISHED] [..]
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
2016-10-07 19:43:48 +00:00
}
#[test]
fn old_version_req_upstream() {
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
2016-10-07 19:43:48 +00:00
[project]
name = "bar"
version = "0.5.0"
authors = []
[dependencies]
remote = "0.3"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
2016-10-07 19:43:48 +00:00
Package::new("remote", "0.3.0")
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
2016-10-07 19:43:48 +00:00
name = "remote"
version = "0.3.0"
authors = []
[dependencies]
bar = "0.2*"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
2018-03-14 15:17:44 +00:00
.publish();
2016-10-07 19:43:48 +00:00
Package::new("bar", "0.2.0").publish();
p.cargo("build")
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
2016-10-07 19:43:48 +00:00
[UPDATING] [..]
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] [..]
2016-10-07 19:43:48 +00:00
warning: parsed version requirement `0.2*` is no longer valid
Previous versions of Cargo accepted this malformed requirement,
but it is being deprecated. This was found when parsing the manifest
of remote 0.3.0, and the correct version requirement is `0.2.*`.
This will soon become a hard error, so it's either recommended to
update to a fixed version or contact the upstream maintainer about
this warning.
[COMPILING] [..]
[COMPILING] [..]
[FINISHED] [..]
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
2016-10-07 19:43:48 +00:00
}
#[test]
fn toml_lies_but_index_is_truth() {
Package::new("foo", "0.2.0").publish();
Package::new("bar", "0.3.0")
2018-03-14 15:17:44 +00:00
.dep("foo", "0.2.0")
.file(
"Cargo.toml",
r#"
[project]
name = "bar"
version = "0.3.0"
authors = []
[dependencies]
foo = "0.1.0"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "extern crate foo;")
2018-03-14 15:17:44 +00:00
.publish();
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "bar"
version = "0.5.0"
authors = []
[dependencies]
bar = "0.3"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
p.cargo("build -v").run();
}
#[test]
fn vv_prints_warnings() {
Package::new("foo", "0.2.0")
.file(
"src/lib.rs",
"#![deny(warnings)] fn foo() {} // unused function",
2018-12-08 11:19:47 +00:00
)
.publish();
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "fo"
version = "0.5.0"
authors = []
[dependencies]
foo = "0.2"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
p.cargo("build -vv").run();
}
#[test]
fn bad_and_or_malicious_packages_rejected() {
Package::new("foo", "0.2.0")
2018-03-14 15:17:44 +00:00
.extra_file("foo-0.1.0/src/lib.rs", "")
.publish();
let p = project()
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
[project]
name = "fo"
version = "0.5.0"
authors = []
[dependencies]
foo = "0.2"
2018-03-14 15:17:44 +00:00
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
p.cargo("build -vv")
.with_status(101)
.with_stderr(
2018-03-14 15:17:44 +00:00
"\
[UPDATING] [..]
2018-09-14 20:33:18 +00:00
[DOWNLOADING] crates ...
[DOWNLOADED] [..]
error: failed to download [..]
Caused by:
failed to unpack [..]
Caused by:
[..] contains a file at \"foo-0.1.0/src/lib.rs\" which isn't under \"foo-0.2.0\"
2018-03-14 15:17:44 +00:00
",
2018-12-08 11:19:47 +00:00
)
.run();
}
#[test]
fn git_init_templatedir_missing() {
Package::new("foo", "0.2.0").dep("bar", "*").publish();
Package::new("bar", "0.2.0").publish();
let p = project()
.file(
"Cargo.toml",
r#"
[project]
name = "fo"
version = "0.5.0"
authors = []
[dependencies]
foo = "0.2"
"#,
2018-12-08 11:19:47 +00:00
)
.file("src/main.rs", "fn main() {}")
.build();
p.cargo("build").run();
remove_dir_all(paths::home().join(".cargo/registry")).unwrap();
File::create(paths::home().join(".gitconfig"))
.unwrap()
.write_all(
br#"
[init]
templatedir = nowhere
"#,
2018-12-08 11:19:47 +00:00
)
.unwrap();
p.cargo("build").run();
p.cargo("build").run();
}
Fix publishing renamed dependencies to crates.io This commit fixes publishing crates which contain locally renamed dependencies to crates.io. Previously this lack of information meant that although we could resolve the crate graph correctly it wouldn't work well with respect to optional features and optional dependencies. The fix here is to persist this information into the registry about the crate being renamed in `Cargo.toml`, allowing Cargo to correctly deduce feature names as it does when it has `Cargo.toml` locally. A dual side of this commit is to publish this information to crates.io. We'll want to merge the associated PR (link to come soon) on crates.io first and make sure that's deployed as well before we stabilize the crate renaming feature. The index format is updated as well as part of this change. The `name` key for dependencies is now unconditionally what was written in `Cargo.toml` as the left-hand-side of the dependency specification. In other words this is the raw crate name, but only for the local crate. A new key, `package`, is added to dependencies (and it can be `None`). This key indicates the crates.io package is being linked against, an represents the `package` key in `Cargo.toml`. It's important to consider the interaction with older Cargo implementations which don't support the `package` key in the index. In these situations older Cargo binaries will likely fail to resolve entirely as the renamed name is unlikely to exist on crates.io. For example the `futures` crate now has an optional dependency with the name `futures01` which depends on an older version of `futures` on crates.io. The string `futures01` will be listed in the index under the `"name"` key, but no `futures01` crate exists on crates.io so older Cargo will generate an error. If the crate does exist on crates.io, then even weirder error messages will likely result. Closes #5962
2018-09-07 16:37:06 +00:00
#[test]
fn rename_deps_and_features() {
Package::new("foo", "0.1.0")
.file("src/lib.rs", "pub fn f1() {}")
.publish();
Package::new("foo", "0.2.0")
.file("src/lib.rs", "pub fn f2() {}")
.publish();
Package::new("bar", "0.2.0")
2018-12-08 11:19:47 +00:00
.add_dep(
Dependency::new("foo01", "0.1.0")
.package("foo")
.optional(true),
)
Fix publishing renamed dependencies to crates.io This commit fixes publishing crates which contain locally renamed dependencies to crates.io. Previously this lack of information meant that although we could resolve the crate graph correctly it wouldn't work well with respect to optional features and optional dependencies. The fix here is to persist this information into the registry about the crate being renamed in `Cargo.toml`, allowing Cargo to correctly deduce feature names as it does when it has `Cargo.toml` locally. A dual side of this commit is to publish this information to crates.io. We'll want to merge the associated PR (link to come soon) on crates.io first and make sure that's deployed as well before we stabilize the crate renaming feature. The index format is updated as well as part of this change. The `name` key for dependencies is now unconditionally what was written in `Cargo.toml` as the left-hand-side of the dependency specification. In other words this is the raw crate name, but only for the local crate. A new key, `package`, is added to dependencies (and it can be `None`). This key indicates the crates.io package is being linked against, an represents the `package` key in `Cargo.toml`. It's important to consider the interaction with older Cargo implementations which don't support the `package` key in the index. In these situations older Cargo binaries will likely fail to resolve entirely as the renamed name is unlikely to exist on crates.io. For example the `futures` crate now has an optional dependency with the name `futures01` which depends on an older version of `futures` on crates.io. The string `futures01` will be listed in the index under the `"name"` key, but no `futures01` crate exists on crates.io so older Cargo will generate an error. If the crate does exist on crates.io, then even weirder error messages will likely result. Closes #5962
2018-09-07 16:37:06 +00:00
.add_dep(Dependency::new("foo02", "0.2.0").package("foo"))
.feature("another", &["foo01"])
.file(
"src/lib.rs",
r#"
extern crate foo02;
#[cfg(feature = "foo01")]
extern crate foo01;
pub fn foo() {
foo02::f2();
#[cfg(feature = "foo01")]
foo01::f1();
}
"#,
)
.publish();
let p = project()
.file(
"Cargo.toml",
r#"
[project]
name = "a"
version = "0.5.0"
authors = []
[dependencies]
bar = "0.2"
"#,
2018-12-08 11:19:47 +00:00
)
.file(
Fix publishing renamed dependencies to crates.io This commit fixes publishing crates which contain locally renamed dependencies to crates.io. Previously this lack of information meant that although we could resolve the crate graph correctly it wouldn't work well with respect to optional features and optional dependencies. The fix here is to persist this information into the registry about the crate being renamed in `Cargo.toml`, allowing Cargo to correctly deduce feature names as it does when it has `Cargo.toml` locally. A dual side of this commit is to publish this information to crates.io. We'll want to merge the associated PR (link to come soon) on crates.io first and make sure that's deployed as well before we stabilize the crate renaming feature. The index format is updated as well as part of this change. The `name` key for dependencies is now unconditionally what was written in `Cargo.toml` as the left-hand-side of the dependency specification. In other words this is the raw crate name, but only for the local crate. A new key, `package`, is added to dependencies (and it can be `None`). This key indicates the crates.io package is being linked against, an represents the `package` key in `Cargo.toml`. It's important to consider the interaction with older Cargo implementations which don't support the `package` key in the index. In these situations older Cargo binaries will likely fail to resolve entirely as the renamed name is unlikely to exist on crates.io. For example the `futures` crate now has an optional dependency with the name `futures01` which depends on an older version of `futures` on crates.io. The string `futures01` will be listed in the index under the `"name"` key, but no `futures01` crate exists on crates.io so older Cargo will generate an error. If the crate does exist on crates.io, then even weirder error messages will likely result. Closes #5962
2018-09-07 16:37:06 +00:00
"src/main.rs",
"
extern crate bar;
fn main() { bar::foo(); }
",
)
.build();
p.cargo("build").run();
p.cargo("build --features bar/foo01").run();
p.cargo("build --features bar/another").run();
}