cargo/Cargo.toml

122 lines
2.9 KiB
TOML
Raw Normal View History

[package]
2014-07-16 00:51:49 +00:00
name = "cargo"
2021-02-12 18:58:38 +00:00
version = "0.53.0"
2018-12-06 19:17:36 +00:00
edition = "2018"
2014-07-16 00:51:49 +00:00
authors = ["Yehuda Katz <wycats@gmail.com>",
2014-11-13 23:08:17 +00:00
"Carl Lerche <me@carllerche.com>",
"Alex Crichton <alex@alexcrichton.com>"]
license = "MIT OR Apache-2.0"
homepage = "https://crates.io"
repository = "https://github.com/rust-lang/cargo"
documentation = "https://docs.rs/cargo"
readme = "README.md"
description = """
Cargo, a package manager for Rust.
"""
2014-07-16 00:51:49 +00:00
2014-08-16 20:00:46 +00:00
[lib]
2014-07-16 00:51:49 +00:00
name = "cargo"
path = "src/cargo/lib.rs"
2014-12-19 03:01:37 +00:00
[dependencies]
atty = "0.2"
Update the progress bar for parallel downloads This is actually a super tricky problem. We don't really have the capacity for more than one line of update-able information in Cargo right now, so we need to squeeze a lot of information into one line of output for Cargo. The main constraints this tries to satisfy are: * At all times it should be clear what's happening. Cargo shouldn't just hang with no output when downloading a crate for a long time, a counter ideally needs to be decreasing while the download progresses. * If a progress bar is shown, it shouldn't jump around. This ends up just being a surprising user experience for most. Progress bars should only ever increase, but they may increase at different speeds. * Cargo has, currently, at most one line of output (as mentioned above) to pack information into. We haven't delved into fancier terminal features that involve multiple lines of update-able output. * When downloading crates as part of `cargo build` (the norm) we don't actually know ahead of time how many crates are being downloaded. We rely on the calculation of unit dependencies to naturally feed into downloading more crates. * Furthermore, once we decide to download a crate, we don't actually know how big it is! We have to wait for the server to tell us how big it is. There doesn't really seem to be a great solution that satisfies all of these constraints unfortunately. As a result this commit implements a relatively conservative solution which should hopefully get us most of the way there. There isn't actually a progress bar but rather Cargo prints that it's got N crates left to download, and if it takes awhile it prints out that there are M bytes remaining. Unfortunately the progress is pretty choppy and jerky, not providing a smooth UI. This appears to largely be because Cargo will synchronously extract tarballs, which for large crates can cause a noticeable pause. Cargo's not really prepared internally to perform this work on helper threads, but ideally if it could do so it would improve the output quite a bit! (making it much smoother and also able to account for the time tarball extraction takes).
2018-09-13 03:57:01 +00:00
bytesize = "1.0"
2019-12-10 19:59:06 +00:00
cargo-platform = { path = "crates/cargo-platform", version = "0.1.1" }
cargo-util = { path = "crates/cargo-util", version = "0.1.0" }
2021-01-22 19:06:51 +00:00
crates-io = { path = "crates/crates-io", version = "0.33.0" }
crossbeam-utils = "0.8"
crypto-hash = "0.3.1"
2019-10-01 07:39:57 +00:00
curl = { version = "0.4.23", features = ["http2"] }
curl-sys = "0.4.22"
env_logger = "0.8.1"
pretty_env_logger = { version = "0.4", optional = true }
anyhow = "1.0"
filetime = "0.2.9"
flate2 = { version = "1.0.3", default-features = false, features = ["zlib"] }
git2 = "0.13.16"
2020-12-18 18:13:50 +00:00
git2-curl = "0.14.1"
glob = "0.3.0"
hex = "0.4"
home = "0.5"
humantime = "2.0.0"
ignore = "0.4.7"
2018-12-11 01:58:06 +00:00
lazy_static = "1.2.0"
2020-02-06 19:30:07 +00:00
jobserver = "0.1.21"
lazycell = "1.2.0"
libc = "0.2"
2018-12-11 01:58:06 +00:00
log = "0.4.6"
libgit2-sys = "0.12.18"
memchr = "2.1.3"
num_cpus = "1.0"
2019-05-03 08:28:12 +00:00
opener = "0.4"
percent-encoding = "2.0"
rustfix = "0.5.0"
same-file = "1"
semver = { version = "0.10", features = ["serde"] }
serde = { version = "1.0.123", features = ["derive"] }
serde_ignored = "0.1.0"
serde_json = { version = "1.0.30", features = ["raw_value"] }
2019-05-12 00:35:25 +00:00
strip-ansi-escapes = "0.1.0"
2020-02-06 19:29:07 +00:00
tar = { version = "0.4.26", default-features = false }
tempfile = "3.0"
termcolor = "1.1"
2020-10-12 18:22:45 +00:00
toml = "0.5.7"
unicode-xid = "0.2.0"
url = "2.0"
2019-03-13 03:33:45 +00:00
walkdir = "2.2"
clap = "2.31.2"
2018-06-29 17:39:35 +00:00
unicode-width = "0.1.5"
openssl = { version = '0.10.11', optional = true }
im-rc = "15.0.0"
# A noop dependency that changes in the Rust repository, it's a bit of a hack.
# See the `src/tools/rustc-workspace-hack/README.md` file in `rust-lang/rust`
# for more information.
rustc-workspace-hack = "1.0.0"
Implement future incompatibility report support cc rust-lang/rust#71249 This implements the Cargo side of 'Cargo report future-incompat' Based on feedback from alexcrichton and est31, I'm implemented this a flag `--future-compat-report` on `cargo check/build/rustc`, rather than a separate `cargo describe-future-incompatibilities` command. This allows us to avoid writing additional information to disk (beyond the pre-existing recording of rustc command outputs). This PR contains: * Gating of all functionality behind `-Z report-future-incompat`. Without this flag, all user output is unchanged. * Passing `-Z emit-future-incompat-report` to rustc when `-Z report-future-incompat` is enabled * Parsing the rustc JSON future incompat report, and displaying it it a user-readable format. * Emitting a warning at the end of a build if any crates had future-incompat reports * A `--future-incompat-report` flag, which shows the full report for each affected crate. * Tests for all of the above. At the moment, we can use the `array_into_iter` to write a test. However, we might eventually get to a point where rustc is not currently emitting future-incompat reports for any lints. What would we want the cargo tests to do in this situation? This functionality didn't require any significant internal changes to Cargo, with one exception: we now process captured command output for all units, not just ones where we want to display warnings. This may result in a slightly longer time to run `cargo build/check/rustc` from a full cache. since we do slightly more work for each upstream dependency. Doing this seems unavoidable with the current architecture, since we need to process captured command outputs to detect any future-incompat-report messages that were emitted.
2020-10-29 21:48:09 +00:00
rand = "0.8.3"
[target.'cfg(target_os = "macos")'.dependencies]
core-foundation = { version = "0.9.0", features = ["mac_os_10_7_support"] }
[target.'cfg(windows)'.dependencies]
2020-07-25 11:43:19 +00:00
fwdansi = "1.1.0"
2018-07-21 16:35:35 +00:00
2018-01-03 19:25:28 +00:00
[target.'cfg(windows)'.dependencies.winapi]
version = "0.3"
features = [
"basetsd",
2018-01-03 19:25:28 +00:00
"handleapi",
"jobapi",
"jobapi2",
"memoryapi",
2018-01-03 19:25:28 +00:00
"minwindef",
"ntdef",
"ntstatus",
2018-01-03 19:25:28 +00:00
"processenv",
"processthreadsapi",
"psapi",
"synchapi",
"winerror",
"winbase",
"wincon",
"winnt",
]
[dev-dependencies]
cargo-test-macro = { path = "crates/cargo-test-macro" }
cargo-test-support = { path = "crates/cargo-test-support" }
[build-dependencies]
flate2 = { version = "1.0.3", default-features = false, features = ["zlib"] }
tar = { version = "0.4.26", default-features = false }
2014-07-16 00:51:49 +00:00
[[bin]]
name = "cargo"
test = false
2014-08-14 21:54:56 +00:00
doc = false
[features]
deny-warnings = []
2019-10-01 07:39:57 +00:00
vendored-openssl = ["openssl/vendored"]
pretty-env-logger = ["pretty_env_logger"]