Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upI think that for an option library like uuid, its feature can be reexported at the same time. #1669
Comments
This comment has been minimized.
|
This wouldn't solve your original problem, as the |
This comment has been minimized.
driftluo
commented
Apr 29, 2018
|
However, when I write it like this, my project is working properly: [dependencies.uuid]
features = ["serde", "v4"]
version = "^0.6.0"
[dependencies.diesel]
features = ["postgres", "chrono", "uuid", "r2d2"]
version = "^1.1.1"On I think diesel features add the following:
I will be able to use this instead of reimport the uuid library just to turn on an features: [dependencies.diesel]
features = ["postgres", "chrono", "uuid", "r2d2", "v4"]
version = "^1.1.1" |
This comment has been minimized.
driftluo
commented
Apr 29, 2018
•
|
Ok, I looked at the source code, uuid is converted from |
This comment has been minimized.
|
I do not want to re-export every feature of every optional dependency we support |
This comment has been minimized.
|
While I can appreciate the sentiment here, I don't think this approach makes sense in Diesel. For most applications, they will likely want to enable at least one feature on the other crates (usually |
driftluo commentedApr 29, 2018
Issue:
Diesel 1.1.* only support uuid 0.5.*, and I use uuid need its v4 feature, so on my Cargo.toml will be:
But diesel 1.2.* support to uuid 0.6.*, when I
cargo update, uuid doesn't update to 0.6, then will Rustc will complain like follow:So, I think that for an option library like uuid, its feature can be reexported at the same time. In this way, you do not need to pay attention to the version of the corresponding library, let it upgrade at the same time with the diesel.
If you accept this view, I will submit a pull request to complete this function.