Closed Ilia-Kosenkov closed 1 year ago
This looks good, but is it the re-exporting that allows you to simplify this, or is it just the fact that e.g. the ndarray
feature depends on the ndarray
crate, making dependency calculation logic redundant? Re-exporting would be a Rust thing whereas this is purely a cargo.toml
thing, right?
So the reasoning is the following: somewhere during either
integration with extendr
we discussed & decided that it is ok to export third-party crates from extendr
(I think it is encouraged in Rust community). With that in mind, when a feature is enabled, a respective crate (if any) is automatically re-exported through extendr
namespace. If you enable either
, you can immediately use Either
, Left
, Right
if you reference extendr_api::prelude::*
. Thus, there is no need to install crate dependency explicitly, and I removed this feature in this PR. As a result, {rextendr}
logic is simplified.
Of course you can reference any crate explicitly, but then you get several 'versions' of it available, one directly referenced, another -- exported through extendr
. Since we are talking about dynamic compilation here, I seriously doubt there is a scenario when someone enables ndarray
but then separately references ndarray
of a different version to achieve something.
Okay, I guess it's indirectly related to re-exporting, because it mean extendr users can use dependencies of features without adding those dependencies as top level dependencies.
extendr
re-exports crates when they are behind a feature gate, so there is no real need to automatically add reference for third-party crates.Also update how warnings are raised, following the example of
extendr_fn_options
, not raising warnings whenuse_dev_extendr = TRUE
.Closes #253