nabijaczleweli / cargo-update Goto Github PK
View Code? Open in Web Editor NEWA cargo subcommand for checking and applying updates to installed executables
License: MIT License
A cargo subcommand for checking and applying updates to installed executables
License: MIT License
Maybe I'm just not setting an environment variable that I should be - but building fails with error: failed to run custom build command for 'libgit2-sys v0.6.15'
. I should probably file this with git2-rs, but I can't really verify that git2-rs breaks because I don't use it.
Also note that I have the Homebrew packages for openssl and libssh2 installed.
If this is a path configuration thing, it also might be nice to have that as part of the readme.
Attaching a log to be somewhat helpful
log.txt
Thanks
Not sure what's going wrong, here is the result:
$ RUST_BACKTRACE=1 cargo install cargo-update
Updating registry `https://github.com/rust-lang/crates.io-index`
Compiling array_tool v0.3.3
Compiling utf8-ranges v0.1.3
Compiling regex-syntax v0.3.9
Compiling libc v0.2.18
Compiling unicode-width v0.1.3
Compiling cargo-update v0.6.2
Compiling json v0.11.3
Compiling strsim v0.5.2
Compiling memchr v0.1.11
Compiling tabwriter v0.1.25
Compiling lazy_static v0.2.2
Compiling aho-corasick v0.5.3
Compiling winapi v0.2.8
Compiling bitflags v0.7.0
Compiling ansi_term v0.9.0
Build failed, waiting for other jobs to finish...
error: failed to compile `cargo-update v0.6.2`, intermediate artifacts can be found at `C:\Users\VICTOR~1\AppData\Local\Temp\cargo-install.O2vS7XrFsGJe`
Caused by:
failed to run custom build command for `cargo-update v0.6.2`
process didn't exit successfully: `C:\Users\VICTOR~1\AppData\Local\Temp\cargo-install.O2vS7XrFsGJe\release\build\cargo-update-32000c146366c1f1\build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Are you sure you have RC.EXE in your $PATH?: Error { repr: Os { code: 2, message: "The system cannot find the file specified." } }', ../src/libcore\result.rs:799
stack backtrace:
0: 0x7ff702fe0a94 - <std::io::error::ErrorKind as core::fmt::Debug>::fmt::h4c8259105642d5e7
1: 0x7ff702fdecd3 - std::rt::lang_start::h538f8960e7644c80
2: 0x7ff702fdf5dd - std::panicking::rust_panic_with_hook::hc303199e04562edf
3: 0x7ff702fdf476 - std::panicking::begin_panic_fmt::hc321cece241bb2f5
4: 0x7ff702fdf394 - std::panicking::begin_panic_fmt::hc321cece241bb2f5
5: 0x7ff702fdf32b - rust_begin_unwind
6: 0x7ff702fe4285 - core::panicking::panic_fmt::h27224b181f9f037f
7: 0x7ff702fd116f - __ImageBase
8: 0x7ff702fd1721 - __ImageBase
9: 0x7ff702fe2f61 - _rust_maybe_catch_panic
10: 0x7ff702fde70a - std::rt::lang_start::h538f8960e7644c80
11: 0x7ff702fe7298 - __scrt_common_main_seh
at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
12: 0x7ffe8a848101 - BaseThreadInitThunk
What is RC.EXE and why does it have to be in my $PATH?
Hi,
I've opened a pull request (#320) at awesome-rust (at the end of the build system section) to feature cargo-update as I've been using it for the last months and it's been incredibly handy.
Is there a reason why this repo should not be featured? I can't see why not, I just want to make sure there's no problem with cargo-update I'm not aware of.
See: #23 (comment)
RUST_BACKTRACE=1 cargo install-update -a
Updating registry `https://github.com/rust-lang/crates.io-index`
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:329
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
0: cargo_update::ops::MainRepoPackage::pull_version
1: cargo_install_update::main
Basically there are 2 strategies:
If found a new version of cargo-update, then the program could:
cargo install cargo-update --force
, and exitDon't know which one is better and/or easier to implement and maintain, just FYI.
Edit: The first one have a timing issue (cargo-update must exit before the new command starts), so the second one is better.
To quote /u/dzamlo on Roddit (@dzamlo here?):
There is one feature I think is missing: an option to list packages that need an update, but without updating them.
I see that this was discussed previously in #10 and #30 but as far as I can tell, it was never coherently explained why cargo-update needs to do this differently.
Synopsis of previous thread and some points of my own:
The Cargo FAQ is very explicit about when Cargo.lock is supposed to be checked in. It writes:
It is recommended that all binaries check in their Cargo.lock.
The reasons are explained in the link.
The rebuttal to this point in #10 (comment) was:
<nabijaczleweli> But this is a library
After being pointed out that the crate does contain binaries, the follow-up was:
<nabijaczleweli> think of the exec like an example, which it basically is (and should be)
While you may see it this way, I haven't found any evidence that any code anywhere uses cargo-update as a library. On crates.io there are zero crates that depend on cargo-update. On GitHub there are zero Cargo.toml manifests that depend on cargo-update. Everybody only uses the binaries.
In #30 (comment) it was pointed out that adding Cargo.lock does not affect how this crate is used as a library. Quoting again from the same Cargo FAQ:
Users dependent on the library will not inspect the library’s Cargo.lock (even if it exists).
Cargo will use the lockfile for building the binary, while crates that depend on the library will ignore the lockfile. This means we get all the benefits of shipping a Cargo.lock with an exclusively binary crate.
$ cargo install-update -al
spawns a "cargo" search ""
which is runs forever.
cargo 0.23.0 (61fa02415 2017-11-22)
cargo-update v1.3.2
win7 x64
Nightly cargo behaves the same.
I have encountered such issue time ago with the same version, but was not sure about the reason (was it due to 1.3.2 or new cargo may be). Just tried to reinstall cargo-update which helped me.
However now it freezes again. But I have to say that on another pc cargo search ""
does not freeze. So, the problem is that cargo install-update
spawns the empty cargo search
.
Hi
I am currently working on mac, but I can not compile the openssl crate without messing up the system with homebrew...
Is there a way to switch to native-tls?
So I installed a crate from a git repo with something like
cargo install --git <repo> --force --branch <branch>
which seems to break cargo install update:
RUST_BACKTRACE=1 ./target/debug/cargo-install-update install-update -lag
[...]
tokei v7.0.0 v7.0.0 No
tree-rs v0.6.4 v0.6.4 No
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { code: -1, klass: 12, message: "unexpected HTTP status code: 400" }', libcore/result.rs:916:5
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:68
at libstd/sys_common/backtrace.rs:57
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:380
3: std::panicking::default_hook
at libstd/panicking.rs:396
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:576
5: std::panicking::begin_panic
at libstd/panicking.rs:537
6: std::panicking::begin_panic_fmt
at libstd/panicking.rs:521
7: rust_begin_unwind
at libstd/panicking.rs:497
8: core::panicking::panic_fmt
at libcore/panicking.rs:71
9: core::result::unwrap_failed
at /checkout/src/libcore/macros.rs:23
10: <core::result::Result<T, E>>::unwrap
at /checkout/src/libcore/result.rs:782
11: cargo_update::ops::GitRepoPackage::pull_version
at ./src/ops/mod.rs:333
12: cargo_install_update::actual_main
at src/main.rs:167
13: cargo_install_update::main
at src/main.rs:21
14: std::rt::lang_start::{{closure}}
at /checkout/src/libstd/rt.rs:74
15: std::panicking::try::do_call
at libstd/rt.rs:59
at libstd/panicking.rs:479
16: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:102
17: std::rt::lang_start_internal
at libstd/panicking.rs:458
at libstd/panic.rs:358
at libstd/rt.rs:58
18: std::rt::lang_start
at /checkout/src/libstd/rt.rs:74
19: main
20: __libc_start_main
21: _start
cargo-edit
released v0.2.0 following v0.1.6. The new version deprecates the binary cargo-list
. So .crates.toml
now contains:
"cargo-edit 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)" = ["cargo-list"]
"cargo-edit 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = ["cargo-add", "cargo-rm", "cargo-upgrade"]
which if I run cargo install-update -al
leads to:
Package Installed Latest Needs update
cargo-edit v0.1.6 v0.2.0 Yes
cargo-edit v0.2.0 v0.2.0 No
cargo install-update cargo-edit
will compile and install cargo-edit
v0.2.0 again and again instead of saying No packages need updating.
.
Cargo.lock is normally included for projects with a binary. By the way, it's ignored when building as library dependency.
cargo install cargo-update
results in:
error: proc-macro derive panicked
--> .cargo/registry/src/github.com-1ecc6299db9ec823/cargo-update-0.8.1/src/ops/config.rs:43:73
|
43 | #[derive(Debug, Clone, Hash, PartialEq, Eq, PartialOrd, Ord, Serialize, Deserialize)]
| ^^^^^^^^^^^
|
= help: message: proc_macro::__internal::with_parse_sess() called before set_parse_sess()!
error: failed to compile `cargo-update v0.8.1`, intermediate artifacts can be found at `/var/folders/5m/qk85bf793gzdmrgxpd2qrl4m0000gn/T/cargo-install.iDIiPXoPMRKd`
I'm on macOS 10.12.4
The cargo install
command has a --debug
flag, as in cargo install mdbook --debug
. So something like:
cargo install-update mdbook --debug
This is useful for tools that compile slowly in release mode but run fast enough even in debug mode.
cannot open input file 'cargo-install-update-manifest.lib'
that .lib was not created by build.rs
with argment -a
or -al
:
C:\WINDOWS\system32>cargo install-update -a
Updating registry `https://github.com/rust-lang/crates.io-index`
Package Installed Latest Needs update
rustfmt v0.4.1 v0.6.2 Yes
rustfmt v0.6.2 v0.6.2 No
cargo-edit v0.1.2 v0.1.3 Yes
cargo-edit v0.1.3 v0.1.3 No
rustfmt
here, but I think they should have to be rustfmt.exe
and cargo-fmt.exe
.cargo-edit
here, but I think they should have to be cargo-add.exe
and cargo-list.exe
.After all packages up to date, no duplicate package names are printed.
I do have CMake installed and I keep getting this error:
error: failed to run custom build command for `libssh2-sys v0.2.6`
process didn't exit successfully: `C:\Users\Ivan\AppData\Local\Temp\cargo-install.LTkoVxeQFh0P\release\build\libssh2-sys-d3fb74f89e26155a\build-script-build` (exit code: 101)
--- stdout
running: "cmake" "C:\\Users\\Ivan\\.cargo\\registry\\src\\github.com-1ecc6299db9ec823\\libssh2-sys-0.2.6\\libssh2" "-G" "Visual Studio 14 2015 Win64" "-DCRYPTO_BACKEND=WinCNG" "-DZLIB_INCLUDE_DIR=C:\\Users\\Ivan\\AppData\\Loca
l\\Temp\\cargo-install.LTkoVxeQFh0P\\release\\build\\libz-sys-26642ca3039fad06\\out/include" "-DBUILD_SHARED_LIBS=OFF" "-DENABLE_ZLIB_COMPRESSION=ON" "-DCMAKE_INSTALL_LIBDIR=lib" "-DBUILD_EXAMPLES=OFF" "-DBUILD_TESTING=OFF" "-
DCMAKE_INSTALL_PREFIX=C:\\Users\\Ivan\\AppData\\Local\\Temp\\cargo-install.LTkoVxeQFh0P\\release\\build\\libssh2-sys-d3774949694dd1df\\out" "-DCMAKE_C_FLAGS= /nologo /MD" "-DCMAKE_C_FLAGS_RELEASE= /nologo /MD" "-DCMAKE_CXX_FLA
GS= /nologo /MD" "-DCMAKE_CXX_FLAGS_RELEASE= /nologo /MD" "-DCMAKE_BUILD_TYPE=Release"
--- stderr
fatal: Not a git repository (or any of the parent directories): .git
thread 'main' panicked at '
failed to execute command: The system cannot find the file specified. (os error 2)
is `cmake` not installed?
build script failed, must exit now', .cargo\registry\src\github.com-1ecc6299db9ec823\cmake-0.1.24\src\lib.rs:593
stack backtrace:
0: std::sys_common::backtrace::_print
at C:\projects\rust\src\libstd\sys_common\backtrace.rs:94
1: std::panicking::default_hook::{{closure}}
at C:\projects\rust\src\libstd\panicking.rs:354
2: std::panicking::default_hook
at C:\projects\rust\src\libstd\panicking.rs:371
3: std::panicking::rust_panic_with_hook
at C:\projects\rust\src\libstd\panicking.rs:549
4: std::panicking::begin_panic<alloc::string::String>
at C:\projects\rust\src\libstd\panicking.rs:511
5: std::panicking::begin_panic_fmt
at C:\projects\rust\src\libstd\panicking.rs:495
6: cmake::Config::build
7: cmake::Config::build
8: cmake::Config::build
9: ZIG_NORM_F
10: panic_unwind::__rust_maybe_catch_panic
at C:\projects\rust\src\libpanic_unwind\lib.rs:98
11: std::rt::lang_start
at C:\projects\rust\src\libstd\rt.rs:52
12: __scrt_common_main_seh
at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
13: BaseThreadInitThunk
warning: build failed, waiting for other jobs to finish...
error: failed to compile `cargo-update v1.1.1`, intermediate artifacts can be found at `C:\Users\Ivan\AppData\Local\Temp\cargo-install.LTkoVxeQFh0P`
Caused by:
build failed
It has a problem linking with iconv, which is somewhere in the dependencies of a git package. I'm on OSX 10.9, but it seems like this is a recurring problem on OSX. A quick google search for iconv and mac showed that.
This wasn't a problem 0.8.1, which is the version I still have installed.
Funny thing is, if I run $> cargo install-update -al
it doesn't list a version 1.0, but if I run $> cargo install -f cargo-update
it does find the 1.0 version and I get the compile error.
It all compiled fine on my ubuntu machine, if I used the second command.
Depends on rust-lang/rfcs#721 landing, undoable for the time being.
Will also require removing the auto-elevation notice from README.
Steps to reproduce:
$ cargo install-update -a
Updating registry `https://github.com/rust-lang/crates.io-index`
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /checkout/src/libcore/option.rs:335:20
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Rust version: 1.22.1 and 1.24 nightly
OS:
Linux 4.13.12-1-ARCH #1 SMP PREEMPT Wed Nov 8 11:54:06 CET 2017 x86_64 GNU/Linux
$ cargo install-update --list
error: The following required arguments were not provided:
<PACKAGE>...
USAGE:
cargo install-update <PACKAGE>... --list
For more information try --help
I usually install crates using stable rustc (and stable cargo), but I want some packages to be built and installed with nightly rustc.
In my case, clippy
(and diesel_cli
in the past) should be (and can only be) built with nightly rustc and cargo.
Additionally, I installed diesel_cli
with cargo option --no-default-features --features="sqlite"
.
Is there any plan to add features (or how-to) to use different toolchains (and build options) for each crate?
Especially for reproducable CI builds, it would be useful to be able to specify the desired version range to install-update to. Currently, if I want to get updates within a semver range, my only option is to cargo install --version ^0.5 --force tarpaulin
(to pick an example). I'd like to be able to cargo install-update --allow-no-update --version ^0.5 tarpaulin
and let install-update handle not reinstalling it if it's been cached.
A new --version
option is added. It takes a VersionReq
specified in the same format as cargo-install
's --version
option. If --version
is specified, exactly one package must be specified.
If the installed version is the same as the latest published version within the specified version requirement, no action is taken. If a later version is available, it is installed by providing the --version
option to cargo-install
.
(Note, I haven't seen how cargo-install-update
is implemented, so I'm trying to keep this high-level enough to be applicable.)
Add a new --version
option. This option takes an object of type semver::VersionReq
. For full compatibility with cargo-install
, it should be attempted to parse as an exact semver::Version
if it doesn't start with one of =
, >
, <
, ~
, or ^
. This can be decided for or against externally to what cargo-install
does, as this is a separate command with different meaning.
When this --version
option is present, fail early with an error message if more than one package are provided as trailing arguments.
Rather than determine the latest semver version as the target version, first filter the list of available versions on the version requirement provided, then select the latest version. Proceed normally with the new target version.
This may require renaming the Latest
column to Target
or something similar when --version
is provided.
Attempting to install fails with a vague error.
PS C:\Users\seekr> rustup show
Default host: x86_64-pc-windows-gnu
nightly-x86_64-pc-windows-gnu (default)
rustc 1.19.0-nightly (557967766 2017-05-26)
PS C:\Users\seekr> cargo install cargo-update
Updating registry `https://github.com/rust-lang/crates.io-index`
Installing cargo-update v1.0.0
Compiling unicode-xid v0.0.4
Compiling unicode-width v0.1.4
Compiling winapi-build v0.1.1
Compiling bitflags v0.8.2
Compiling array_tool v0.3.5
Compiling regex-syntax v0.4.1
Compiling pkg-config v0.3.9
Compiling ansi_term v0.9.0
Compiling vec_map v0.8.0
Compiling unicode-normalization v0.1.4
Compiling quote v0.3.15
Compiling kernel32-sys v0.2.2
Compiling strsim v0.6.0
Compiling synom v0.11.3
Compiling json v0.11.6
Compiling utf8-ranges v1.0.0
Compiling unicode-segmentation v1.2.0
Compiling serde v1.0.8
Compiling syn v0.11.11
Compiling gcc v0.3.49
Compiling tabwriter v1.0.3
Compiling winapi v0.2.8
Compiling embed-resource v1.1.1
Compiling libc v0.2.23
Compiling cargo-update v1.0.0
Compiling rand v0.3.15
error: failed to run custom build command for `cargo-update v1.0.0`
process didn't exit successfully: `C:\Users\seekr\AppData\Local\Temp\cargo-install.ZgXCbqjBSiUy\release\build\cargo-update-87b2aa30f3df4201\build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 2, message: "The system cannot find the file specified." } }', src\libcore\result.rs:859
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Build failed, waiting for other jobs to finish...
error: failed to compile `cargo-update v1.0.0`, intermediate artifacts can be found at `C:\Users\seekr\AppData\Local\Temp\cargo-install.ZgXCbqjBSiUy`
Caused by:
build failed
$ cargo install-update -a
Updating registry `https://github.com/rust-lang/crates.io-index`
Package Installed Latest Needs update
clippy v0.0.123 v0.0.123 No
rustsym v0.3.1 v0.3.1 No
rustfmt v0.8.3 v0.8.3 No
cargo-update v0.8.0 v0.8.0 No
ripgrep v0.5.1 v0.5.1 No
racer v2.0.6 v2.0.6 No
No packages need updating.
Reality: https://crates.io/crates/ripgrep
Cargo.toml
ripgrep = "0.6.0"
Versions
0.6.0 Aug 24, 2017
Hello,
On installing i got this:
error: failed to compile cargo-update v1.4.0
, intermediate artifacts can be found at /tmp/cargo-install.JpEXDBLLIpMP
How to fix this?
root@chip:~# cargo --version
cargo 0.23.0 (61fa02415 2017-11-22)
When I tried to install the cargo-update in the normal console (read as: not developer console) as usual, I get:
C:\Users\USERNAME>cargo install cargo-update -f
Updating registry `https://github.com/rust-lang/crates.io-index`
Downloading cargo-update v0.5.2
Downloading json v0.11.1
Compiling ansi_term v0.9.0
Compiling regex-syntax v0.3.9
Compiling rustc-serialize v0.3.21
Compiling winapi v0.2.8
Compiling vec_map v0.6.0
Compiling unicode-width v0.1.3
Compiling strsim v0.5.2
Compiling json v0.11.1
Compiling libc v0.2.17
Compiling array_tool v0.3.3
Compiling winapi-build v0.1.1
Compiling unicode-segmentation v0.1.2
Compiling bitflags v0.7.0
Compiling utf8-ranges v0.1.3
Compiling cargo-update v0.5.2
Compiling lazy_static v0.2.2
Compiling tabwriter v0.1.25
Compiling memchr v0.1.11
Compiling kernel32-sys v0.2.2
Compiling aho-corasick v0.5.3
Build failed, waiting for other jobs to finish...
error: failed to compile `cargo-update v0.5.2`, intermediate artifacts can be found at `C:\Users\USERNAME\AppData\Local\Temp\cargo-install.JYDW3ptfUGzE`
Caused by:
failed to run custom build command for `cargo-update v0.5.2`
process didn't exit successfully: `C:\Users\USERNAME\AppData\Local\Temp\cargo-install.JYDW3ptfUGzE\release\build\cargo-update-6aef32cf34a5954c\build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 2, message: "The system cannot find the file specified." } }', ../src/libcore\result.rs:837
stack backtrace:
0: 0x7ff7bec3114a - std::panicking::default_hook::{{closure}}
at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libstd\panicking.rs:252
1: 0x7ff7bec30656 - std::panicking::default_hook
at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libstd\panicking.rs:263
2: 0x7ff7bec33f4d - std::panicking::rust_panic_with_hook
at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libstd\panicking.rs:451
3: 0x7ff7bec33de8 - std::panicking::begin_panic<collections::string::String>
at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libstd\panicking.rs:413
4: 0x7ff7bec33d04 - std::panicking::begin_panic_fmt
at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libstd\panicking.rs:397
5: 0x7ff7bec33c99 - std::panicking::rust_begin_panic
at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libstd\panicking.rs:373
6: 0x7ff7bec36757 - core::panicking::panic_fmt
at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libcore\panicking.rs:69
7: 0x7ff7bec2108f - POW10TO128
8: 0x7ff7bec21753 - POW10TO128
9: 0x7ff7bec360d1 - panic_unwind::__rust_maybe_catch_panic
at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libpanic_unwind\lib.rs:97
10: 0x7ff7bec3453a - std::rt::lang_start
at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libstd\rt.rs:51
11: 0x7ff7bec39748 - __scrt_common_main_seh
at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
12: 0x7ffc873e8363 - BaseThreadInitThunk
Then I try to re-do this in the developer console, I get:
D:\Microsoft Visual Studio 14.0\VC>cargo install cargo-update -f
Updating registry `https://github.com/rust-lang/crates.io-index`
Compiling utf8-ranges v0.1.3
Compiling lazy_static v0.2.2
Compiling unicode-width v0.1.3
Compiling bitflags v0.7.0
Compiling regex-syntax v0.3.9
Compiling rustc-serialize v0.3.21
Compiling libc v0.2.17
Compiling winapi-build v0.1.1
Compiling json v0.11.1
Compiling vec_map v0.6.0
Compiling array_tool v0.3.3
Compiling unicode-segmentation v0.1.2
Compiling winapi v0.2.8
Compiling strsim v0.5.2
Compiling ansi_term v0.9.0
Compiling cargo-update v0.5.2
Compiling tabwriter v0.1.25
Compiling memchr v0.1.11
Compiling kernel32-sys v0.2.2
Compiling aho-corasick v0.5.3
Compiling toml v0.2.1
Compiling thread-id v2.0.0
Compiling term_size v0.2.1
Compiling thread_local v0.2.7
Compiling clap v2.19.0
Compiling regex v0.1.80
Compiling semver-parser v0.6.1
Compiling semver v0.5.1
Finished release [optimized] target(s) in 251.12 secs
Replacing C:\Users\Mystery\.cargo\bin\cargo-install-update.exe
Obviously, this line in the build.rs tries to .unwrap()
to run the rc
program which is unavailable in the 'normal' console, then aborts the building process.
VS users won't always add the path of the building tools into $PATH
. Also, running cargo and all of its sub-commands won't need a developer console. Since installing the old version of cargo-update won't need the developer console, I hope installing new versions won't need the developer console, too.
cargo install
has a --vers
flag which lets you specify the version to install. Can that be added to this crate?
If it was added this crate would be absoltely perfect!
Just an idea:
instead of cloning the repos into /tmp, it would be awesome if we could instead check if we already have the git repo in ~/CARGO_HOME/git/db/ and if so, update it using cargo and then check "git log " inside the bare repo to determine if the repo needs to be updated.
First, I got an error that cmake was not installed. I installed cmake and then I get the following error
running: "cmake" "--build" "." "--target" "install" "--config" "Release" "--" "-j8"
Scanning dependencies of target libssh2
[ 9%] [ 9%] [ 14%] [ 19%] [ 23%] Building C object src/CMakeFiles/libssh2.dir/agent.c.o
Building C object src/CMakeFiles/libssh2.dir/comp.c.o
Building C object src/CMakeFiles/libssh2.dir/channel.c.o
Building C object src/CMakeFiles/libssh2.dir/openssl.c.o
[ 28%] Building C object src/CMakeFiles/libssh2.dir/crypt.c.o
cc1: error: unrecognized command line option "-std=gnu90"
cc1: error: unrecognized command line option "-std=gnu90"
[ 33%] gmake[2]: *** [src/CMakeFiles/libssh2.dir/agent.c.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[2]: *** [src/CMakeFiles/libssh2.dir/comp.c.o] Error 1
cc1: error: unrecognized command line option "-std=gnu90"
cc1: error: unrecognized command line option "-std=gnu90"
gmake[2]: *** [src/CMakeFiles/libssh2.dir/openssl.c.o] Error 1
gmake[2]: *** [src/CMakeFiles/libssh2.dir/channel.c.o] Error 1
cc1: error: unrecognized command line option "-std=gnu90"
gmake[2]: *** [src/CMakeFiles/libssh2.dir/crypt.c.o] Error 1
Building C object src/CMakeFiles/libssh2.dir/global.c.o
Building C object src/CMakeFiles/libssh2.dir/hostkey.c.o
cc1: error: unrecognized command line option "-std=gnu90"
gmake[2]: *** [src/CMakeFiles/libssh2.dir/global.c.o] Error 1
cc1: error: unrecognized command line option "-std=gnu90"
gmake[2]: *** [src/CMakeFiles/libssh2.dir/hostkey.c.o] Error 1
gmake[1]: *** [src/CMakeFiles/libssh2.dir/all] Error 2
gmake: *** [all] Error 2
--- stderr
fatal: Not a git repository (or any of the parent directories): .git
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_CXX_COMPILER
thread 'main' panicked at '
command did not execute successfully, got: exit code: 2
build script failed, must exit now', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.24/src/lib.rs:593
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Build failed, waiting for other jobs to finish...
error: failed to compile `cargo-update v1.1.1`, intermediate artifacts can be found at `/tmp/cargo-install.UvhJhzltj6lc`
Caused by:
build failed
Hello
Sometimes, I want to install a binary that is not on crates.io, or I want to keep on the very bleeding edge, so I install it with:
cargo install --git https://github.com/whatever/program
Now, it would be great if cargo update could also keep this thing up to date, by checking the installed hash or something and reinstall if master or other relevant branch moves forward.
However, I don't know if it is at all possible (eg. if the git hash is stored somewhere during the installation, for example).
C:\Users\liigo>cargo install-update
error: An unknown error occurred
To learn more, run the command again with --verbose.
C:\Users\liigo>cargo install-update --verbose
error: An unknown error occurred
To learn more, run the command again with --verbose.
If run it as administrator, it works.
Update: to know the reason and workaround, see comments after this
Is cargo-update
capable of updating itself? (Sorry, not so much an issue as a technical question, but I wasn't sure where else to ask it)
Since it works with a fake one, maybe it's unused after all?
Updating registry `https://github.com/rust-lang/crates.io-index`
Package Installed Latest Needs update
cargo-update v1.1.2 v1.3.0 Yes
Updating cargo-update
Updating registry `https://github.com/rust-lang/crates.io-index`
Installing cargo-update v1.3.0
Compiling unicode-normalization v0.1.5
Compiling array_tool v0.4.1
Compiling ansi_term v0.9.0
Compiling openssl-probe v0.1.1
Compiling void v1.0.2
Compiling serde v1.0.15
Compiling matches v0.1.6
Compiling unicode-xid v0.0.4
Compiling json v0.11.10
Compiling quote v0.3.15
Compiling semver-parser v0.7.0
Compiling cc v1.0.0
Compiling bitflags v0.9.1
Compiling vec_map v0.8.0
Compiling unicode-width v0.1.4
Compiling lazy_static v0.2.9
Compiling percent-encoding v1.0.0
Compiling strsim v0.6.0
Compiling regex-syntax v0.4.1
Compiling embed-resource v1.1.4
Compiling utf8-ranges v1.0.0
Compiling libc v0.2.32
Compiling pkg-config v0.3.9
Compiling unreachable v1.0.0
Compiling synom v0.11.3
Compiling unicode-bidi v0.3.4
Compiling tabwriter v1.0.3
Compiling cargo-update v1.3.0
Compiling semver v0.8.0
Compiling thread_local v0.3.4
Compiling atty v0.2.3
Compiling memchr v1.0.1
Compiling term_size v0.3.0
Compiling rand v0.3.17
Compiling syn v0.11.11
Compiling textwrap v0.8.0
Compiling aho-corasick v0.6.3
Compiling idna v0.1.4
Compiling curl-sys v0.3.15
Compiling openssl-sys v0.9.19
Compiling libz-sys v1.0.17
Compiling cmake v0.1.26
Compiling clap v2.26.2
Compiling toml v0.4.5
Compiling lazysort v0.1.1
Compiling url v1.5.1
Compiling libgit2-sys v0.6.16
Compiling libssh2-sys v0.2.6
Compiling regex v0.2.2
Compiling serde_derive_internals v0.16.0
Compiling serde_derive v1.0.15
Compiling git2 v0.6.8
error: linking with `cc` failed: exit code: 1
|
= note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/mateon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/cargo_install_update-6267f375df001c43.0.o" "-o" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/cargo_install_update-6267f375df001c43" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/cargo_install_update-6267f375df001c43.crate.allocator.o" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-nodefaultlibs" "-L" "/tmp/cargo-install.VoH044Bf9uNr/release/deps" "-L" "/tmp/cargo-install.VoH044Bf9uNr/release/build/libgit2-sys-52036b91a199fc9b/out/lib" "-L" "/tmp/cargo-install.VoH044Bf9uNr/release/build/curl-sys-ac94287b2c6d70f3/out/lib" "-L" "/usr/lib/x86_64-linux-gnu" "-L" "/tmp/cargo-install.VoH044Bf9uNr/release/build/libssh2-sys-7eebc093787c06f4/out/lib" "-L" "/home/mateon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libcargo_update-100e8c08598d4ae5.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libsemver-375acf34a88a73f1.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libtoml-aafa554572d0d17c.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libtabwriter-5f06f56c7c0c9e9e.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libarray_tool-0a2f9bbb91d29c64.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libregex-303692458a900971.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libregex_syntax-3535a562df9bbb0d.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libthread_local-f5c04a92ef18184e.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libaho_corasick-498b515a85ee90f0.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libgit2-7a175d59304be499.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libopenssl_probe-1847814eedcfb48d.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/liblibgit2_sys-b2859c3c0c10d935.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/liburl-f7bceb0e78cb3410.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libidna-fc5f2b97807dad43.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libunicode_bidi-8c37f3d295190f5a.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libpercent_encoding-4582de6c18386499.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libjson-f01a661b40c32aff.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/liblazy_static-c821767783c4edaf.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libsemver_parser-25052887fe415dbf.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libmemchr-c0a231da0d9ac9a3.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libunreachable-a52c36c462d94569.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libvoid-464c3aba24657c02.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libutf8_ranges-3c8ca6d3badf85dd.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libmatches-68cbe4810d976d13.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libunicode_normalization-301411a10fa91f08.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/liblibssh2_sys-ca27eff7424c2651.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libcurl_sys-3c829ac76a7c05d5.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libopenssl_sys-e29389d41ed7107c.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/liblibz_sys-bb97ca483542f850.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libclap-a0927af1320b2451.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libatty-c7bdf20b6e51f5ec.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libvec_map-a1c27f67b0f30b08.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libbitflags-80de8df75f46b445.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libansi_term-d027903f865b463f.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libstrsim-9422d6eafe2336c5.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libtextwrap-987ac21a2e486fb0.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libterm_size-846cfaed869167d5.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/liblibc-b408e02024a17a5a.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libunicode_width-655a04edaed1aaad.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/libserde-63210794f3e09ab7.rlib" "/tmp/cargo-install.VoH044Bf9uNr/release/deps/liblazysort-fa02590fa69905c2.rlib" "/home/mateon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-4417e9730e1582e6.rlib" "/home/mateon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-e8dfba60977a6436.rlib" "/home/mateon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-221fb859d65ee0c2.rlib" "/home/mateon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-e2e14a8cd94d84f0.rlib" "/home/mateon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_system-168184ab67c3c4bf.rlib" "/home/mateon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-9a79f9937b41db10.rlib" "/home/mateon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-ddada564b34025bf.rlib" "/home/mateon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_unicode-19e07afc4bd461f5.rlib" "/home/mateon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-49240518d06d7735.rlib" "/home/mateon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-dd5bba80e2402629.rlib" "/home/mateon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-e043d51b15904669.rlib" "-Wl,-Bdynamic" "-l" "ssl" "-l" "crypto" "-l" "z" "-l" "util" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util"
= note: /tmp/cargo-install.VoH044Bf9uNr/release/deps/libcurl_sys-3c829ac76a7c05d5.rlib(libcurl_la-url.o): In function `fix_hostname.isra.9':
url.c:(.text.fix_hostname.isra.9+0x58): undefined reference to `idn2_check_version'
url.c:(.text.fix_hostname.isra.9+0x78): undefined reference to `idn2_lookup_ul'
url.c:(.text.fix_hostname.isra.9+0xb3): undefined reference to `idn2_strerror'
/tmp/cargo-install.VoH044Bf9uNr/release/deps/libcurl_sys-3c829ac76a7c05d5.rlib(libcurl_la-url.o): In function `Curl_disconnect':
url.c:(.text.Curl_disconnect+0x9f): undefined reference to `idn2_free'
url.c:(.text.Curl_disconnect+0xbb): undefined reference to `idn2_free'
url.c:(.text.Curl_disconnect+0xd7): undefined reference to `idn2_free'
url.c:(.text.Curl_disconnect+0xf3): undefined reference to `idn2_free'
/tmp/cargo-install.VoH044Bf9uNr/release/deps/libcurl_sys-3c829ac76a7c05d5.rlib(libcurl_la-url.o): In function `Curl_connect':
url.c:(.text.Curl_connect+0x7b7): undefined reference to `idn2_free'
/tmp/cargo-install.VoH044Bf9uNr/release/deps/libcurl_sys-3c829ac76a7c05d5.rlib(libcurl_la-url.o):url.c:(.text.Curl_connect+0x7d3): more undefined references to `idn2_free' follow
/tmp/cargo-install.VoH044Bf9uNr/release/deps/libcurl_sys-3c829ac76a7c05d5.rlib(libcurl_la-version.o): In function `curl_version.part.0':
version.c:(.text.curl_version.part.0+0x80): undefined reference to `idn2_check_version'
version.c:(.text.curl_version.part.0+0x8c): undefined reference to `idn2_check_version'
/tmp/cargo-install.VoH044Bf9uNr/release/deps/libcurl_sys-3c829ac76a7c05d5.rlib(libcurl_la-version.o): In function `curl_version_info.part.1':
version.c:(.text.curl_version_info.part.1+0x37): undefined reference to `idn2_check_version'
collect2: error: ld returned 1 exit status
error: aborting due to previous error
error: failed to compile `cargo-update v1.3.0`, intermediate artifacts can be found at `/tmp/cargo-install.VoH044Bf9uNr`
Caused by:
Could not compile `cargo-update`.
To learn more, run the command again with --verbose.
Updated 0 packages.
Failed to update cargo-update.
Cargo make a local of the registry (in .cargo/registry). It should be faster to use it instead of asking crates.io for each package.
The local registry should be updated before checking for new versions.
I just noticed that a couple of my installed packages are shown as updated on crates.io, but the newer versions are not showing up with cargo install-update
. For example:
% cargo search cargo-check
Updating registry `https://github.com/rust-lang/crates.io-index`
cargo-check (0.2.2) wrapper around cargo rustc -- -Zno-trans
...
% cargo install-update -a
Updating registry `https://github.com/rust-lang/crates.io-index`
Package Installed Latest Needs update
cargo-check v0.2.1 v0.2.1 No
I'm currently running version 0.5.1, which looks like the latest.
EDIT: Forgot to mention, this is on an x86_64 linux machine
As per the Cargo reference, for programs, Cargo.lock should be in the repository.
I'd like to be able to specify a version to install when using cargo install-update -i
. I'd like to be able to use this in travis to install a pinned version of packages like rustfmt/clippy without needing to manually check if the package is installed or the correct version.
cargo-update
fails to install.
[bash] ~: rustc --version
rustc 1.18.0-nightly (28a742997 2017-04-13)
[bash] ~: cargo install cargo-update
Updating registry `https://github.com/rust-lang/crates.io-index`
Installing cargo-update v0.8.0
Compiling strsim v0.6.0
Compiling void v1.0.2
Compiling lazy_static v0.2.8
Compiling ansi_term v0.9.0
Compiling json v0.11.6
Compiling vec_map v0.7.0
Compiling unicode-segmentation v1.1.0
Compiling unicode-width v0.1.4
Compiling unreachable v0.1.1
Compiling array_tool v0.3.4
Compiling tabwriter v1.0.3
Compiling libc v0.2.21
Compiling regex-syntax v0.4.0
Compiling serde v0.9.13
Compiling bitflags v0.8.2
Compiling quote v0.3.15
Compiling embed-resource v1.1.1
Compiling unicode-xid v0.0.4
Compiling cargo-update v0.8.0
Compiling semver-parser v0.7.0
Compiling synom v0.11.3
Compiling memchr v1.0.1
Compiling term_size v0.3.0
Compiling rand v0.3.15
Compiling syn v0.11.10
Compiling thread-id v3.0.0
Compiling utf8-ranges v1.0.0
Compiling thread_local v0.3.3
Compiling aho-corasick v0.6.3
Compiling semver v0.6.0
Compiling atty v0.2.2
Compiling clap v2.23.2
Compiling lazysort v0.1.1
Compiling toml v0.3.2
Compiling regex v0.2.1
Compiling serde_codegen_internals v0.14.2
Compiling serde_derive v0.9.13
error: couldn't read ".cargo/registry/src/github.com-1ecc6299db9ec823/cargo-update-0.8.0/src/bin/cargo-install-update.rs": No such file or directory (os error 2)
error: Could not compile `cargo-update`.
Build failed, waiting for other jobs to finish...
error: failed to compile `cargo-update v0.8.0`, intermediate artifacts can be found at `/tmp/cargo-install.B0YOp9aGjRxe`
Caused by:
build failed
Running cargo install-update cargo-update
that results in a compile failure (e.g. because rc.exe wasn't in the path) leaves the .cargo/bin
executables in a bad state. I ended up with at bad cargo-install-update.exe
file that was 0 bytes (and not a symlink) and a cargo-install-update.exe-0.6.2
file that was the previous version. The original executable was not restored and I had to manually restore it in order to run the update again (with the proper path).
rust-lang/cargo#4026 introduced local registry without checkout, and this tool doesn't work since it relies on registry directory structure.
The old format isn't compatible with the new format at all, so choose one:
cargo install-update -l -a
simply finds no packages for me. I suspect it fails to read the ~/.cargo/config
where the installation directory is redirected to where it is supposed to be:
[install]
root = "/home/me/.local"
Just to track occurrences of https://users.rust-lang.org/t/crates-io-compatibility-with-old-cargo/9127/23
See also rust-lang/crates.io#580
$ cargo install --verbose cargo-update
Updating registry `https://github.com/rust-lang/crates.io-index`
failed to compile `cargo-update v0.8.1`, intermediate artifacts can be found at `/home/ubuntu/target-install`
Caused by:
failed to parse registry's information for: serde_derive
Caused by:
the given version requirement is invalid
$ cargo -V
cargo 0.8.0 (built 2016-03-22)
$ rustc -V
rustc 1.7.0
I recently did a cargo install-update --all
and in this case clippy-lints
failed to compile. It looks like cargo-update
exits on the first compile error because afterwards running cargo install-update --list --all
shows that there are still packages with updates available.
I had to manually update the others because cargo-update
can't get past clippy-lints
. Can you set it up so that instead of exiting on the first compilation error, cargo-update
just skips that package and moves onto the next? Then at the end you could print a message saying something like "5 packages updated. The following package(s) failed to compile: cargo-clippy" to let the user know what happened.
I have installed i3status-rust
from its git repo, and it hasn't had a commit in 4 days, but when I run cargo install-update -ag
it tries to update it due to it listing a different hash. This has happened with other packages install through git
One feature I've wondered about for awhile would be to have parallel update tasks running. I have a very powerful desktop, with a 8-core/16-thread R7 1700X processor. When there are half a dozen packages to be updated, a large portion of the update process is spent in a single thread during the final stages of each package. Since only one update happens at a time, these final stage processes are sequential, making the update process very slow compared to what it could be.
If I could choose to run multiple package updates in parallel, then their final, sequential stage would run in parallel, greatly reducing the time to do the updates.
My preferred approach would be to naively run the specified number of package updates in parallel, allowing the operating system to sort out who gets access to the processor, but an approach that you might find more reasonable would be to artificially restrict each package update to a fraction of the processor. With cargo install-update -a -j4
, we could have 4 update jobs running in parallel. On a 16-thread machine, each of these 4 jobs could be run with cargo install -j4 ...
to equally divide the processor threads among the update tasks.
If this were to be implemented, it would be nice to have an option or sentinel value to just start all jobs simultaneously, so I don't have to count up how many updates need to be done and supply that number to the parameter.
Hi
I tried to debug this because I have ion-shell
installed, but I can not see why it crashed.
However all the versions of the crate have been yanked.
MainRepoPackage {
name: "ion-shell",
version: Some(
Version {
major: 1,
minor: 0,
patch: 5,
pre: [],
build: []
}
),
newest_version: None,
max_version: None
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.