Cargo features user experience #627
Comments
madsmtm
added
question
Hmm, I guess they could all be enabled by default, though it really is a lot of code that's being compiled (
Yes there is, it's called |
|
Oh, I had no idea about the "magic string" Personally I don't mind waiting 9 seconds for something to compile if it saves me 30 minutes of debugging/enabling features. However, I can see how having the capability to turn features on/off is beneficial (especially for libraries). I would expect the linker to remove the unused code but that may not be enabled by default?
I was copy-pasting the Maybe a new section in the main |
|
I've been thinking about this again, and perhaps it would indeed make sense to make all features be enabled by default, and allowing users to opt out with |
|
With the I only wish it was more prominently visible in the README so that when I add a crate I can configure it correctly. I started a new project this morning and I had to find this thread 😃 I worry that if everything is enabled by default users (specifically users who depend on objc2-* transitively) will complain about long compile times. |
Yeah, that's part of why I've left this issue open, I still want to improve the docs on this!
That's also a worry of mine, and I know that some people reflexively use |
Enable (almost) all framework crate features by default, to make the user experience when developing binaries (not libraries) much easier. Users that develop a library should use `default-features = false`, but that's also probably something that they only want to do later in the development process (and should be evaluated on a case-by-case basis). Fixes #627 This also makes examples much nicer to run, it's just `cargo run --example $name`, no need to configure all the required features.
Enable (almost) all framework crate features by default, to make the user experience when developing binaries (not libraries) much easier. Users that develop a library should use `default-features = false`, but that's also probably something that they only want to do later in the development process (and should be evaluated on a case-by-case basis). Fixes #627 This also makes examples much nicer to run, it's just `cargo run --example $name`, no need to configure all the required features.
Enable (almost) all framework crate features by default, to make the user experience when developing binaries (not libraries) much easier. Users that develop a library should use `default-features = false`, but that's also probably something that they only want to do later in the development process (and should be evaluated on a case-by-case basis). Fixes #627 This also makes examples much nicer to run, it's just `cargo run --example $name`, no need to configure all the required features.
madsmtm
added
bug
Enable (almost) all framework crate features by default, to make the user experience when developing binaries (not libraries) much easier. Users that develop a library should use `default-features = false`, but that's also probably something that they only want to do later in the development process (and should be evaluated on a case-by-case basis). Fixes #627 This also makes examples much nicer to run, it's just `cargo run --example $name`, no need to configure all the required features.
|
I have moved the items in the It is somewhat unfortunate that I didn't do this originally, since once I do the release, I'll have to go file PRs to all the projects that currently use I'll also note that there was a slight complication here, namely that we don't want |
|
Wouldn't it make sense to create a set of feature to enable functionality needed? Like if metal mandates 61 feature, maybe have a feature for that? Like enabling all will likely make them not being disabled in some dependency in the graph and blow up. Like even for said metal, like I'd also said that win32 has a common problem, but doesn't try to enable everything by default. |
|
Yes, and we had that before, the In my own use of the Basically, enabling all features should be the default, since that's always what you want when starting out. Yes, this will cause some crates to enable too much, but that's a cost we'll have to live with. If need be, I guess I could analyse Python script to do so```python import json import urllib.request import sysAPI_URL = "https://crates.io/api/v1/crates" crate_name = sys.argv[1] page = 1 |
The next version of the `objc2` framework crates will have a bunch of default features enabled, see madsmtm/objc2#627, so this PR pre-emptively disables them, so that your compile times down blow up once you upgrade to the next version (which is yet to be released, but will be soon). * [x] I have followed the instructions in the PR template
As I mentioned earlier, excellent work on these libraries and generators!
That said, I find it frustrating to have to specify the feature for every class I want to use (
objc2-metalhas 61 features). Should features be enabled by default and libraries that want to reduce code only specify the functionality they need?I understand that this might be necessary when one crate extends the functionality of another.
Is there a Cargo feature to enable every feature of a crate?
The text was updated successfully, but these errors were encountered: