This brings the features used by the `nu_plugin_fetch` and
`nu_plugin_post` in line and drops the default-features, reducing
the number of pulled-in dependencies and avoiding a second round of
compilations.
Signed-off-by: Daniel Egger <daniel@eggers-club.de>
* kind of works but not what we really want
* updated `into binary` and `first` to work better together
* attempt to fix wasm build problem
* attempt #2 to fix wasm stuff
This brings with it a reduction in the number of duplicated
dependencies that it has and the overhead it imposes on our
build.
The number of crates that need to be built for
`cargo build --features extra` drops by roughly 50.
On Windows, we used the `is-exeuctable` crate but on Unix, we
duplicated the check that it did, with one difference: We also
looked at whether or not it was a symlink.
The `is-executable` crate uses `std::fs::metadata` which follows
symlinks, so this scenario should never occur here, as it will
return the metadata for the target file.
Using the `is-executable` crate on both Unix and Windows lets us
make it non-optional. This lets us remove the `executable-support`
feature. (It is worth noting that this code didn't compile on
Windows when the `executable-support` feature was not specified.)
Right now, there is an alternate code path for `target_arch` being
`wasm32`. This isn't exactly correct as it should probably handle
something different for when the `target_os` is `wasi`.
Nothing used the `ptree` feature or optional dependency within
`nu-command` except to include it within the `version` output. This
may be related to when `nu-cli` also had a `ptree` feature, but
I'm not sure.
That leaves the code within `nu_plugin_tree` as the sole remaining
user of `ptree`, which is already covered by the feature `tree`
and included in the `version` output.
