{"action":"closed","issue":{"url":"https://api.github.com/repos/rust-lang/cargo/issues/2823","repository_url":"https://api.github.com/repos/rust-lang/cargo","labels_url":"https://api.github.com/repos/rust-lang/cargo/issues/2823/labels{/name}","comments_url":"https://api.github.com/repos/rust-lang/cargo/issues/2823/comments","events_url":"https://api.github.com/repos/rust-lang/cargo/issues/2823/events","html_url":"https://github.com/rust-lang/cargo/issues/2823","id":163550385,"number":2823,"title":"Disabling default features from a distant crate","user":{"login":"IvanUkhov","id":57440,"avatar_url":"https://avatars.githubusercontent.com/u/57440?v=3","gravatar_id":"","url":"https://api.github.com/users/IvanUkhov","html_url":"https://github.com/IvanUkhov","followers_url":"https://api.github.com/users/IvanUkhov/followers","following_url":"https://api.github.com/users/IvanUkhov/following{/other_user}","gists_url":"https://api.github.com/users/IvanUkhov/gists{/gist_id}","starred_url":"https://api.github.com/users/IvanUkhov/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/IvanUkhov/subscriptions","organizations_url":"https://api.github.com/users/IvanUkhov/orgs","repos_url":"https://api.github.com/users/IvanUkhov/repos","events_url":"https://api.github.com/users/IvanUkhov/events{/privacy}","received_events_url":"https://api.github.com/users/IvanUkhov/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2016-07-03T06:55:29Z","updated_at":"2016-07-09T06:07:03Z","closed_at":"2016-07-09T06:07:03Z","body":"Currently, if crate `B` depends on crate `A`, and crate `A` has default feature `f`, crate `B` starts to depend on the feature (unless `default-features = false`). As a result, crate `C` dependent on `B` has no way of opting out of `f` (unless `B` is willing to reexport `f` as its own feature).\r\n\r\nThe motivation behind this behavior, I guess, is that, since `B` hasn’t disabled `f`, it really needs it in order to function properly. For instance, `f` might be enriching the API of `A`. Some features, however, are not like that. They don’t alter the API but instead switch between alternative implementations, for example. In such cases, it’s very unfortunate that `C` doesn’t have control over `f`. `C`’s developers have to kindly ask `B`’s developers to reexport and keep in sync `A`’s baggage.\r\n\r\nA potential solution is to allow any crate in the dependency graph (in our case, `C`) to disable the default features of any other crate (in our case, `A`) by depending on that second crate directly and setting `default-features = false`. If `B` really needs some additional codes provided by `f`, the compilation will simply fail. It shouldn’t lead to serious logic errors. In any case, it’s `C`’s responsibility to make sure that everything works as it should.\r\n\r\nI’m curious if there are any strong objections to the above. Thanks!\r\n\r\nRegards,\r\nIvan"}}
{"actor":{"display_login":"IvanUkhov"}}