cargo/tests/testsuite/registry.rs

1919 lines
43 KiB
Rust
Raw Normal View History

use std::fs::{self, File};
use std::io::prelude::*;
use std::path::PathBuf;
use cargo::util::paths::remove_dir_all;
use support::cargo_process;
use support::git;
use support::paths::{self, CargoPathExt};
use support::registry::{self, Package};
use support::{execs, project};
use support::hamcrest::assert_that;
use url::Url;
2018-03-14 15:17:44 +00:00
fn registry_path() -> PathBuf {
paths::root().join("registry")
}
fn registry() -> Url {
Url::from_file_path(&*registry_path()).ok().unwrap()
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("bar", "0.0.1").publish();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
[UPDATING] registry `{reg}`
2017-10-04 22:07:01 +00:00
[DOWNLOADING] bar v0.0.1 (registry `file://[..]`)
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 ({dir})
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-03-14 15:17:44 +00:00
dir = p.url(),
reg = registry::registry()
)),
);
2014-09-09 14:23:09 +00:00
assert_that(p.cargo("clean"), execs().with_status(0));
2014-09-09 14:23:09 +00:00
// Don't download a second time
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
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 ({dir})
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-03-14 15:17:44 +00:00
dir = p.url()
)),
);
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("baz", "0.0.1").publish();
Package::new("bar", "0.0.1").dep("baz", "*").publish();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
[UPDATING] registry `{reg}`
2017-10-04 22:07:01 +00:00
[DOWNLOADING] [..] v0.0.1 (registry `file://[..]`)
[DOWNLOADING] [..] v0.0.1 (registry `file://[..]`)
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 ({dir})
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-03-14 15:17:44 +00:00
dir = p.url(),
reg = registry::registry()
)),
);
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(101).with_stderr(
"\
2016-05-20 00:21:55 +00:00
[UPDATING] registry [..]
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-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"
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
// #5678 to make this work
2018-07-09 22:02:46 +00:00
assert_that(
p.cargo("build"),
execs().with_status(101).with_stderr(
"\
[UPDATING] registry [..]
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 ([..])`
",
),
);
}
#[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"
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
// #2775 to make this work
2018-07-09 22:02:46 +00:00
assert_that(
p.cargo("build"),
execs().with_status(101).with_stderr(
"\
[UPDATING] registry [..]
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 ([..])`
",
),
);
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("foo", "0.0.1").publish();
Package::new("foo", "0.0.2").publish();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(101).with_stderr_contains(
"\
2018-02-07 16:51:40 +00:00
error: no matching version `>= 1.0.0` found for package `foo`
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 [..]
versions found: 0.0.2, 0.0.1
2018-02-07 16:51:40 +00:00
required by package `foo v0.0.1 ([..])`
2018-03-14 15:17:44 +00:00
",
),
);
Package::new("foo", "0.0.3").publish();
Package::new("foo", "0.0.4").publish();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(101).with_stderr_contains(
"\
2018-02-07 16:51:40 +00:00
error: no matching version `>= 1.0.0` found for package `foo`
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 [..]
versions found: 0.0.4, 0.0.3, 0.0.2, ...
2018-02-07 16:51:40 +00:00
required by package `foo v0.0.1 ([..])`
2018-03-14 15:17:44 +00:00
",
),
);
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
let pkg = Package::new("bad-cksum", "0.0.1");
pkg.publish();
t!(File::create(&pkg.archive_dst()));
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build").arg("-v"),
execs().with_status(101).with_stderr(
"\
2016-05-20 00:21:55 +00:00
[UPDATING] registry [..]
[DOWNLOADING] bad-cksum [..]
[ERROR] unable to get packages from source
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:
2017-10-04 22:07:01 +00:00
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:
2017-10-04 22:07:01 +00:00
failed to verify the checksum of `bad-cksum v0.0.1 (registry `file://[..]`)`
2018-03-14 15:17:44 +00:00
",
),
);
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(101).with_stderr_contains(
"\
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
",
),
);
Package::new("notyet", "0.0.1").publish();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
[UPDATING] registry `{reg}`
2017-10-04 22:07:01 +00:00
[DOWNLOADING] notyet v0.0.1 (registry `file://[..]`)
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 ({dir})
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-03-14 15:17:44 +00:00
dir = p.url(),
reg = registry::registry()
)),
);
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
2018-03-14 15:17:44 +00:00
.file(
"notyet/Cargo.toml",
r#"
[package]
name = "notyet"
version = "0.0.1"
authors = []
2018-03-14 15:17:44 +00:00
"#,
)
.file("notyet/src/lib.rs", "")
.build();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("package").arg("-v"),
execs().with_status(101).with_stderr_contains(
"\
[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
",
),
);
Package::new("notyet", "0.0.1").publish();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("package"),
execs().with_status(0).with_stderr(format!(
"\
[PACKAGING] foo v0.0.1 ({dir})
[VERIFYING] foo v0.0.1 ({dir})
[UPDATING] registry `[..]`
2017-10-04 22:07:01 +00:00
[DOWNLOADING] notyet v0.0.1 (registry `file://[..]`)
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 ({dir}[..])
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
2018-03-14 15:17:44 +00:00
",
dir = p.url()
)),
);
}
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
"#,
)
.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
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
[UPDATING] registry `[..]`
2017-10-04 22:07:01 +00:00
[DOWNLOADING] bar v0.0.1 (registry `file://[..]`)
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 ({dir})
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-03-14 15:17:44 +00:00
dir = p.url()
)),
);
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
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("build"), execs().with_status(0).with_stdout(""));
}
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
"#,
)
.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
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
[UPDATING] registry `[..]`
2017-10-04 22:07:01 +00:00
[DOWNLOADING] [..] v0.0.1 (registry `file://[..]`)
[DOWNLOADING] [..] v0.0.1 (registry `file://[..]`)
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 ({dir})
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-03-14 15:17:44 +00:00
dir = p.url()
)),
);
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
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("build"), execs().with_status(0).with_stdout(""));
}
#[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
"#,
)
.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();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
[UPDATING] registry `[..]`
2017-10-04 22:07:01 +00:00
[DOWNLOADING] [..] v0.0.1 (registry `file://[..]`)
[DOWNLOADING] [..] v0.0.1 (registry `file://[..]`)
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 ({dir})
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-03-14 15:17:44 +00:00
dir = p.url()
)),
);
}
#[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
"#,
)
.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();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(101).with_stderr_contains(
"\
2018-02-07 16:51:40 +00:00
error: no matching version `= 0.0.2` found for package `baz`
location searched: registry `[..]`
versions found: 0.0.1
2018-02-07 16:51:40 +00:00
required by package `bar v0.0.1`
2018-03-14 15:17:44 +00:00
",
),
);
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("bar", "0.0.1").publish();
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("build"), execs().with_status(0));
registry::registry_path().join("3").rm_rf();
Package::new("bar", "0.0.1").yanked(true).publish();
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("build"), execs().with_status(0).with_stdout(""));
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("update"),
execs().with_status(101).with_stderr_contains(
"\
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
",
),
);
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("bar", "0.0.1").publish();
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("build"), execs().with_status(0));
p.root().move_into_the_past();
paths::home().join(".cargo/registry").rm_rf();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(
"\
[UPDATING] registry `[..]`
2017-10-04 22:07:01 +00:00
[DOWNLOADING] bar v0.0.1 (registry `file://[..]`)
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
2018-03-14 15:17:44 +00:00
",
),
);
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
println!("0.0.1");
Package::new("bar", "0.0.1").publish();
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("build"), execs().with_status(0));
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");
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("update")
.arg("-p")
.arg("bar")
.arg("--precise")
.arg("0.0.2"),
execs().with_status(0).with_stderr(
"\
[UPDATING] registry `[..]`
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
",
),
);
println!("0.0.2 build");
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
2017-10-04 22:07:01 +00:00
[DOWNLOADING] [..] v0.0.2 (registry `file://[..]`)
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 ({dir})
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-03-14 15:17:44 +00:00
dir = p.url()
)),
);
println!("0.0.3 update");
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("update").arg("-p").arg("bar"),
execs().with_status(0).with_stderr(
"\
[UPDATING] registry `[..]`
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
",
),
);
println!("0.0.3 build");
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
2017-10-04 22:07:01 +00:00
[DOWNLOADING] [..] v0.0.3 (registry `file://[..]`)
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 ({dir})
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-03-14 15:17:44 +00:00
dir = p.url()
)),
);
println!("new dependencies update");
Package::new("bar", "0.0.4").dep("spam", "0.2.5").publish();
Package::new("spam", "0.2.5").publish();
assert_that(
p.cargo("update").arg("-p").arg("bar"),
execs().with_status(0).with_stderr(
"\
[UPDATING] registry `[..]`
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
",
),
);
println!("new dependencies update");
Package::new("bar", "0.0.5").publish();
assert_that(
p.cargo("update").arg("-p").arg("bar"),
execs().with_status(0).with_stderr(
"\
[UPDATING] registry `[..]`
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
",
),
);
}
#[test]
2018-03-14 15:17:44 +00:00
fn update_offline() {
use support::ChannelChanger;
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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("update")
.masquerade_as_nightly_cargo()
.arg("-Zoffline"),
execs()
.with_status(101)
.with_stderr("error: you can't update in the offline mode[..]"),
);
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("baz", "0.0.1").publish();
Package::new("bar", "0.0.1").dev_dep("baz", "*").publish();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
[UPDATING] registry `[..]`
2017-10-04 22:07:01 +00:00
[DOWNLOADING] [..] v0.0.1 (registry `file://[..]`)
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 ({dir})
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-03-14 15:17:44 +00:00
dir = p.url()
)),
);
}
#[test]
fn login_with_no_cargo_dir() {
let home = paths::home().join("new-home");
t!(fs::create_dir(&home));
2018-03-14 15:17:44 +00:00
assert_that(
cargo_process().arg("login").arg("foo").arg("-v"),
execs().with_status(0),
);
}
2016-08-16 20:51:08 +00:00
#[test]
fn login_with_differently_sized_token() {
// Verify that the configuration file gets properly trunchated.
let home = paths::home().join("new-home");
t!(fs::create_dir(&home));
2018-03-14 15:17:44 +00:00
assert_that(
cargo_process().arg("login").arg("lmaolmaolmao").arg("-v"),
execs().with_status(0),
);
assert_that(
cargo_process().arg("login").arg("lmao").arg("-v"),
execs().with_status(0),
);
assert_that(
cargo_process().arg("login").arg("lmaolmaolmao").arg("-v"),
execs().with_status(0),
);
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
"#,
)
.file(
"src/main.rs",
r#"
fn main() {}
2018-03-14 15:17:44 +00:00
"#,
)
.build();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("publish")
.arg("-v")
.arg("--index")
.arg(registry().to_string()),
2018-03-14 15:43:41 +00:00
execs()
.with_status(101)
.with_stderr_contains("[ERROR] the license file `foo` does not exist"),
2018-03-14 15:17:44 +00:00
);
}
#[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
"#,
)
.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
"#,
)
.file("a/src/lib.rs", "")
.build();
Package::new("bar", "0.0.1").publish();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
[UPDATING] registry `[..]`
2017-10-04 22:07:01 +00:00
[DOWNLOADING] bar v0.0.1 (registry `file://[..]`)
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 ({dir}/a)
[COMPILING] foo v0.0.1 ({dir})
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-03-14 15:17:44 +00:00
dir = p.url()
)),
);
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");
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
[UPDATING] registry `[..]`
2017-10-04 22:07:01 +00:00
[DOWNLOADING] bar v0.1.0 (registry `file://[..]`)
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 ({dir}/a)
[COMPILING] foo v0.0.1 ({dir})
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-03-14 15:17:44 +00:00
dir = p.url()
)),
);
}
#[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
"#,
)
.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()
),
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("a", "0.0.1").publish();
p.root().move_into_the_past();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
[UPDATING] [..]
[UPDATING] [..]
2017-10-04 22:07:01 +00:00
[DOWNLOADING] a v0.0.1 (registry `file://[..]`)
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 ({dir})
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-03-14 15:17:44 +00:00
dir = p.url()
)),
);
p.root().move_into_the_past();
println!("second");
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("build"), execs().with_status(0).with_stdout(""));
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("a", "0.1.0").publish();
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("build"), execs().with_status(0));
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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
2018-03-14 15:17:44 +00:00
assert_that(p2.cargo("build"), execs().with_status(0));
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.
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(&format!(
"\
[UPDATING] [..]
2017-10-04 22:07:01 +00:00
[DOWNLOADING] a v0.1.1 (registry `file://[..]`)
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 ({dir})
2018-05-02 12:52:40 +00:00
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]s
",
2018-03-14 15:17:44 +00:00
dir = p.url()
)),
);
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("a", "0.1.0").publish();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("fetch"),
execs().with_status(0).with_stderr(
"\
[UPDATING] registry `[..]`
[DOWNLOADING] a v0.1.0 (registry [..])
2018-03-14 15:17:44 +00:00
",
),
);
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
Package::new("a", "0.1.0").dep("b", "*").publish();
Package::new("b", "0.1.0").publish();
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("fetch"), execs().with_status(0));
Package::new("b", "0.1.1").publish();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("update").arg("-pb"),
execs().with_status(0).with_stderr(
"\
[UPDATING] registry `[..]`
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-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(
"\
2017-10-04 22:07:01 +00:00
[DOWNLOADING] b v0.1.1 (registry `file://[..]`)
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
",
),
);
}
#[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
"#,
)
.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();
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("generate-lockfile"), execs().with_status(0));
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();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("update").arg("-p").arg("hyper"),
execs().with_status(0).with_stderr(
"\
[UPDATING] registry `[..]`
[UPDATING] hyper v0.6.5 -> v0.6.6
[UPDATING] openssl v0.1.0 -> v0.1.1
",
),
2018-03-14 15:17:44 +00:00
);
}
#[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
"#,
)
.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();
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("fetch"), execs().with_status(0));
Package::new("a", "0.1.1").publish();
Package::new("b", "0.1.1").publish();
Package::new("c", "0.1.1").publish();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("update").arg("-pa").arg("-pb"),
execs().with_status(0).with_stderr(
"\
[UPDATING] registry `[..]`
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-03-14 15:17:44 +00:00
assert_that(
p.cargo("update").arg("-pb").arg("-pc"),
execs().with_status(0).with_stderr(
"\
[UPDATING] registry `[..]`
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
",
),
);
assert_that(
p.cargo("build"),
execs()
.with_status(0)
2018-03-14 15:43:41 +00:00
.with_stderr_contains("[DOWNLOADING] a v0.1.1 (registry `file://[..]`)")
.with_stderr_contains("[DOWNLOADING] b v0.1.1 (registry `file://[..]`)")
.with_stderr_contains("[DOWNLOADING] c v0.1.1 (registry `file://[..]`)")
.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 ([..])"),
2018-03-14 15:17:44 +00:00
);
}
#[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
"#,
)
.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
"#,
)
.file("src/lib.rs", "")
2018-03-14 15:17:44 +00:00
.file(
"bar/Cargo.toml",
r#"
[package]
name = "bar"
version = "0.1.0"
authors = []
2018-03-14 15:17:44 +00:00
"#,
)
.file("bar/src/lib.rs", "")
.publish();
assert_that(p.cargo("run"), execs().with_status(0));
}
#[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
"#,
)
.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();
assert_that(p.cargo("generate-lockfile"), execs().with_status(0));
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("update").arg("-pfoobar").arg("--precise=0.2.0"),
execs().with_status(0),
);
}
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
"#,
)
.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
assert_that(p.cargo("build"), execs().with_status(0));
}
#[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
"#,
)
.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();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(
"\
[UPDATING] registry `[..]`
[DOWNLOADING] 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
",
),
);
}
#[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
"#,
)
.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();
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("build"), execs().with_status(0));
}
#[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
"#,
)
.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();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build").arg("-vv"),
2018-03-14 15:43:41 +00:00
execs()
.with_status(0)
.with_stderr_contains("[..]warning: function is never used[..]"),
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
#[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
"#,
)
.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
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build").arg("--frozen"),
execs().with_status(101).with_stderr(
"\
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
",
),
);
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
"#,
)
.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
"#,
)
.file("baz/src/lib.rs", "")
.build();
Package::new("remote", "0.3.4").publish();
assert_that(p.cargo("build"), execs().with_status(0));
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
"#
));
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(
"\
[COMPILING] bar v0.5.0 ([..])
[FINISHED] [..]
2018-03-14 15:17:44 +00:00
",
),
);
}
#[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
"#,
)
.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
"#,
)
.file("baz/src/lib.rs", "")
.build();
Package::new("remote", "0.3.4").publish();
assert_that(p.cargo("build"), execs().with_status(0));
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
"#
));
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(
"\
[COMPILING] bar v0.6.0 ([..])
[FINISHED] [..]
2018-03-14 15:17:44 +00:00
",
),
);
}
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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
2016-10-07 19:43:48 +00:00
Package::new("remote", "0.2.0").publish();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(
"\
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] [..]
[DOWNLOADING] [..]
[COMPILING] [..]
[COMPILING] [..]
[FINISHED] [..]
2018-03-14 15:17:44 +00:00
",
),
);
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
"#,
)
.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
"#,
)
.file("src/lib.rs", "")
.publish();
2016-10-07 19:43:48 +00:00
Package::new("bar", "0.2.0").publish();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build"),
execs().with_status(0).with_stderr(
"\
2016-10-07 19:43:48 +00:00
[UPDATING] [..]
[DOWNLOADING] [..]
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
",
),
);
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
"#,
)
.file("src/lib.rs", "extern crate foo;")
.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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("build").arg("-v"), execs().with_status(0));
}
#[test]
fn vv_prints_warnings() {
Package::new("foo", "0.2.0")
2018-03-14 15:17:44 +00:00
.file(
"src/lib.rs",
r#"
#![deny(warnings)]
fn foo() {} // unused function
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 = "fo"
version = "0.5.0"
authors = []
[dependencies]
foo = "0.2"
2018-03-14 15:17:44 +00:00
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
2018-03-14 15:17:44 +00:00
assert_that(p.cargo("build").arg("-vv"), execs().with_status(0));
}
#[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
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
2018-03-14 15:17:44 +00:00
assert_that(
p.cargo("build").arg("-vv"),
execs().with_status(101).with_stderr(
"\
[UPDATING] [..]
[DOWNLOADING] [..]
error: unable to get packages from source
Caused by:
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
",
),
);
}
#[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"
"#,
)
.file("src/main.rs", "fn main() {}")
.build();
assert_that(
p.cargo("build"),
execs().with_status(0)
);
remove_dir_all(paths::home().join(".cargo/registry")).unwrap();
File::create(paths::home().join(".gitconfig"))
.unwrap()
.write_all(br#"
[init]
templatedir = nowhere
"#)
.unwrap();
assert_that(
p.cargo("build"),
execs().with_status(0)
);
assert_that(
p.cargo("build"),
execs().with_status(0)
);
}