[Feat]: cargo-marker should download the pre-compiled marker_rustc_driver binary from GitHub releases
#238
Labels
A-marker-cargo
Area: All things connected to `cargo_marker`
C-enhancement
Category: New feature or request
Comments
Veetaha
added
C-enhancement
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
xFrednet
added
A-marker-cargo
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 10, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 16, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Veetaha
added a commit
to Veetaha/marker
that referenced
this issue
Sep 19, 2023
This PR adds two new CI workflows `release` and `release-on-tag`. The release process and artifacts are described in `docs/internal/release.md`, so I won't repeat it here. The other change made in this PR is the addition of `package.rust_version` property to `Cargo.toml` of the library crates `marker_api`, `marker_uitest`, `marker_utils`. I was thinking to refactor the layout of the crates in the repo to separate the library crates that have a strict MSRV, and the pre-compiled crates that depend on the pinned nightly toolchain version (rust-marker#193 (comment)), but I decided to do that for now. It's not a big deal, and I don't want to extend this PR with even more changes for that. The scope of this PR doesn't include the code changes in `cargo-marker` to make it use the pre-compiled `marker_rustc_driver` from the GitHub release artifacts, falling back to `cargo install` if that doesn't work. That should be implemented in the scope of rust-marker#238.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
This is the continuation of #193. In that issue, we already discussed the flow where
cargo-markerneeds to download the pre-compiled binary ofmarker_rustc_driverand fall back to compiling from source if that is not available for the current platform (#193 (comment)). There should also be a CLI and config flag to force compiling the driver from source even if a pre-compiled binary is available for security-conscious people.This feature will make the installation blazingly fast ⚡. When writing code for this make sure to handle the network errors, and timeouts and retries with exponential backoff and jitter as usual for all the networking stuff. We have a safe fallback to
cargo installin case GitHub servers aren't responding or the pre-compiled binaries were failed to compile on our release build CI.The text was updated successfully, but these errors were encountered: