Auto-install Rust compiler toolchain locally for CI and JS devs of other projects #1373
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
peaBerberian
added
the
work-in-progress
peaBerberian
force-pushed
the
misc/auto-install-script
branch
from
5ca37f2 to
ae66587
Compare
peaBerberian
force-pushed
the
misc/auto-install-script
branch
18 times, most recently
from
1cfab65 to
52f75d0
Compare
Since we brought the WebAssembly MPD parser to fix performance issues we
had with some contents at canal+, we added another language (Rust) to
the project which is not compatible with most of the JS-world tools we and
other JS developers usually deal with.
Now that we added the `MULTI_THREAD` experimental feature and embeds,
the WebAssembly generation from that other language is even a required
step in our main build script (`npm run build`).
Consequently, when another developer or a CI needs to build an RxPlayer
(e.g. to test a development before a release is made), they have to
install:
1. NodeJS + npm
2. our JavaScript dependencies
3. A Rust toolchain able to output WebAssembly. We generally go
through `rustup` here basically an helper tool to install Rust
toolchains
4. `binaryen`, which is a collection of tools to transform that
WebAssembly file.
(1) and (2) are very common use cases that both JS people and CI workflows
do very easily: they mostly already have nodejs + npm installed locally
(or it's very simple to set-up) and the second is only an `npm install`
call away.
(3) and (4) however, though not hard (you have to install rustup and
binaryen which is pretty simple on all platforms we relied on), are more
unusual dependencies that JS developers might be reticent to install and
that are more work to set-up on a CI.
Consequently I'm doing here a proof-of-concept where those tools are
auto-installed locally if not found when doing an `npm run build` call,
letting both people and CI produce a build easily without having to deal
with the dual-language complexity.
---
For rustup it's pretty straightforward as their install script already
take care of the platform detection, target installation and so on. All
I had to do is to make sure binaries were installed locally (`./tmp`) and
did not pollute the developers environment (e.g. no `PATH`
modification).
For binaryen however, it's less simple as they don't propose such
auto-install system.
however, I noticed that they propose prebuilt binaries for the most usual
platforms on their github's release page:
https://github.com/WebAssembly/binaryen/releases
The idea here (not yet finished), is to automatically detect the
platform of the user and fetch the right binaryen binary locally to then
rely on both it and the local rustup to produce builds in case the
command isn't available globally.
Also, because it will be faster and less error-prone for frequent
developers to install both of those globally once and for all, we print a
notice explaining what we do when that auto-install script is run.
peaBerberian
force-pushed
the
misc/auto-install-script
branch
from
52f75d0 to
7c75820
Compare
Since we brought the WebAssembly MPD parser to fix performance issues we
had with some contents at canal+, we added another language (Rust) to
the project which is not compatible with most of the JS-world tools we and
other JS developers usually deal with.
Now that we added the `MULTI_THREAD` experimental feature and embeds,
the WebAssembly generation from that other language is even a required
step in our main build script (`npm run build`).
Consequently, when another developer or a CI needs to build an RxPlayer
(e.g. to test a development before a release is made), they have to
install:
1. NodeJS + npm
2. our JavaScript dependencies
3. A Rust toolchain able to output WebAssembly. We generally go
through `rustup` here basically an helper tool to install Rust
toolchains
4. `binaryen`, which is a collection of tools to transform that
WebAssembly file.
(1) and (2) are very common use cases that both JS people and CI workflows
do very easily: they mostly already have nodejs + npm installed locally
(or it's very simple to set-up) and the second is only an `npm install`
call away.
(3) and (4) however, though not hard (you have to install rustup and
binaryen which is pretty simple on all platforms we relied on), are more
unusual dependencies that JS developers might be reticent to install and
that are more work to set-up on a CI.
Consequently I'm doing here a proof-of-concept where those tools are
auto-installed locally if not found when doing an `npm run build` call,
letting both people and CI produce a build easily without having to deal
with the dual-language complexity.
---
For rustup it's pretty straightforward as their install script already
take care of the platform detection, target installation and so on. All
I had to do is to make sure binaries were installed locally (`./tmp`) and
did not pollute the developers environment (e.g. no `PATH`
modification).
For binaryen however, it's less simple as they don't propose such
auto-install system.
however, I noticed that they propose prebuilt binaries for the most usual
platforms on their github's release page:
https://github.com/WebAssembly/binaryen/releases
The idea here (not yet finished), is to automatically detect the
platform of the user and fetch the right binaryen binary locally to then
rely on both it and the local rustup to produce builds in case the
command isn't available globally.
Also, because it will be faster and less error-prone for frequent
developers to install both of those globally once and for all, we print a
notice explaining what we do when that auto-install script is run.
peaBerberian
added
Priority: 0 (Very high)
peaBerberian
changed the title
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since we brought the WebAssembly MPD parser to fix performance issues we had with some contents at canal+, we added another language (Rust) to the project which is not compatible with most of the JS-world tools we and other JS developers usually deal with.
Now that we added the
MULTI_THREADexperimental feature and embeds, the WebAssembly generation from that other language is even a required step in our main build script (npm run build).Consequently, when another developer or a CI needs to build an RxPlayer (e.g. to test a development before a release is made), they have to install:
rustuphere basically an helper tool to install Rust toolchainsbinaryen, which is a collection of tools to transform that WebAssembly file.(1) and (2) are very common use cases that both JS people and CI workflows do very easily: they mostly already have nodejs + npm installed locally (or it's very simple to set-up) and the second is only an
npm installcall away.(3) and (4) however, though not hard (you have to install rustup and binaryen which is pretty simple on all platforms we relied on), are more unusual dependencies that JS developers might be reticent to install and that are more work to set-up on a CI (it's fine on ours, but we also sometimes want other projects, with their own CI, to test our developments for their use cases).
Consequently I'm doing here a proof-of-concept where those tools are auto-installed locally if not found when doing an
npm run buildcall, letting both people and CI produce a build easily without having to deal with the dual-language complexity.For rustup it's pretty straightforward as their install script already take care of the platform detection, WebAssembly target installation and so on. All I had to do is to make sure binaries were installed locally (
./tmp) and did not pollute the developers' environment (e.g. noPATHmodification).For binaryen however, it's less simple as they don't propose such auto-install system.
However, I noticed that they propose prebuilt binaries for the most usual platforms on their github's release page:
https://github.com/WebAssembly/binaryen/releases
The idea here (not yet finished), is to automatically detect the platform of the user and fetch the right binaryen binary locally to then rely on both it and the local rustup to produce builds in case the command isn't available globally.
Also, because it will be faster and less error-prone for frequent developers to install both of those globally once and for all, we print a notice explaining what we do when that auto-install script is run.