This lets us leverage `cargo` for semver finding and then ensure that we get the
exact same version of the CLI that cargo selected. It also lets us support fuzzy
dependencies like "0.2" instead of exact dependencies like "0.2.21" again.
This commit kicks off the addition of installers for wasm-pack, with the main
goals of being:
* Users should have a one-click (ideally) solution to download and install
wasm-pack.
* We should ideally not have to worry about picking up "heavy" dependencies in
wasm-pack like C++ or C code (if necessary).
The general idea here is very similar to rustup (and in fact a good deal of code
is copied from them!). The installation worklow for wasm-pack in theory after
this commit looks like:
1. First, a users visits the installer landing page. A preview is available at
https://alexcrichton.github.io/wasm-pack/installer/. Clearly this page needs
a better stylesheet!
2. The user performs the instructions presented on the page. The website
automatically detects what platform you're running on, basically giving you a
curl/sh script or a Windows installer. There's various options for seeing
other installers as well, and the fallback of `cargo install` is presented if
we don't recognize the platform (or if we don't think we have precompiled
binaries).
3a. On Unix, users execute a curl/sh script like:
```
curl https://alexcrichton.github.io/wasm-pack/installer/init.sh -sSf | sh
```
This command will download the shell script included in this PR, which will
in turn do some further platform detection (like OSX vs Linux) and then
download the most recent version of `wasm-pack` from GitHub releases. This
is then extracted, the `wasm-pack` binary is renamed to `wasm-pack-init`,
and then that binary is run. The binary will refuse by default to overwrite
a previous installation, but that can be overridden with the `-f` flag.
3b. On Windows users download a binary. This binary, when run, will pop up a
console window. This window will have the same output as the shell script
installer, and will wait at the end of its execution to ensure the user has
time to read everything.
And... that's it! The deployment process for all this looks like so:
* All CI builds will update the website and shell script (published to
gh-pages). A small script at `docs/installer/build-installer.rs` fills in the
current version number inferred from `Cargo.toml`.
* Tagged CI builds will publish releases, as usual.
* "Pushing a release" is done by bumping the version number in `Cargo.toml`.
When bumped all online installers will now point to the new release. There
will be a window of time, though, when the version number is bumped and the
release hasn't finished building on CI. In this case users will get errors
(unfortunately).
This is all still a work-in-progress and feedback is definitely appreicated and
welcome on all this!
If a test is going to do a potentially destructive operation, instead of
mutating shared fixtures, it should copy the fixture to its own unique directory
and then mutate that copy (doesn't this sound like Rust's borrowing and
ownership rules?! ^.^)
The standard library version of an `RwLock` may get poisoned if a thread
panics that holds a write lock. The `RwLock` from parking_lot [1] does
not get poisoned it instead released the lock on a panic. This allows us
to simplify the `ProgressOutput` API since it no longer returns any
errors. No more panics can occur on `ProgressOutput::drop()`. The
`Error` enum can thus be simplified as well because there is no need to
convert `PoisonErrors` anymore.
[1] https://github.com/Amanieu/parking_lot
This commit does a few things:
- Sets up the ability to log information based off log level
- Figures out where to log the file
- Starts logging information in the program
As this is a first pass the logging is good enough to know where things
went wrong, but we can expand on this in the future to log many many
things. We just now have an initial implementation. The log is written
out to a file that can be read by the user if they pass in -v, -vv, etc.
where each v is an extra level of logging.
Remove quicli from the code base. It's a fantastic library to get
started, but in order to implement logging as well as just maintaining
the library in general it was easier to remove it and continue work
without it. While we were going to remove it in 0.4 we found it easier
to remove now to implement logging.
This commit allows us to have a global progress bar to write data to
giving us the following benefits:
- Consistent ways to handle types of messages such as errors and
warnings
- Easy interface to add progress bars of various types
- Easy to maintain, add new types of bars, or more while encapsulating
the login in a single module
Ashley Williams