Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature names cannot always be free of placeholder words #164

Closed
rushmorem opened this issue Apr 16, 2018 · 2 comments
Closed

Feature names cannot always be free of placeholder words #164

rushmorem opened this issue Apr 16, 2018 · 2 comments

Comments

@rushmorem
Copy link

rushmorem commented Apr 16, 2018

The recommendation for C-FEATURE says:-

Do not call the feature use-std or with-std or any creative name that is not std.

I like this naming convention. Unfortunately, it's not always possible to follow. For example, say I want to add optional support for serde, the obvious name for such a feature would be serde. However, if some of my types can be derived automatically, I would also want to optionally depend on serde_derive. Part of my manifest will then end up as follows:

[features]
serde = ["serde", "serde_derive"]

[dependencies]
serde = { version = "1", optional = true }
serde_derive = { version = "1", optional = true }

However, this is not possible since feature names must not conflict with other package names in the manifest. In such a case, I will either have to use a name like with-serde or come up with a creative name for my feature.

Edit: Had forgotten to insert a hyperlink

@dtolnay
Copy link
Member

dtolnay commented Apr 16, 2018

You should be using serde = { version = "1.0", optional = true, features = ["derive"] }.

https://serde.rs/feature-flags.html#-feature-derive
https://github.com/serde-rs/serde/blob/v1.0.38/serde/src/lib.rs#L245-L283

@rushmorem
Copy link
Author

Awesome! Glad to know that there is already a workaround for this for serde. Thanks @dtolnay :)

It's still an issue for crates that don't implement such workarounds and potentially other use cases but closing in favour of rust-lang/cargo#1286.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants