Per-component features for icu_capi

[makotokato]

When I am testing icu_capi in Gecko, icu_capi cannot select components excepting to provider. Example, when I want segmenter FFI only, icu_capi has to build all components such as datetime unfortunately. Since Gecko uses cargo vendor, I don't want to copy/build unused components in Gecko's source tree.

So I hope that icu_capi has more features to select icu_* components only such as feature = ["datetime", "colletor"].

[sffc]

The benefit of this change is unclear other than reduced build times. It doesn't have an effect on cargo vendor, and component crates have very few dependencies outside of ICU4X anyway.

I'm not opposed to it, but icu_capi already has a lot of features, so I want to make sure this change is well-motivated before we do it.

[Manishearth]

I also want this: it will have an effect on Google3 vendoring at least; and @iwsfutcmd indicated that being able to import a small deptree would help his case for using ICU4X.

I'm not convinced by "component crates have very few dependencies outside of ICU4X anyway" because the component crates are themselves dependencies and we have quite a few of them.

Also, we already do this for the metacrate.

I do think we should have default_components and experimental_components feature groups so most people don't need to manually toggle stuff if they're using --no-default-features for other reasons.

[Manishearth]

See also: #3165

[sffc]

Okay, go ahead with the component-level features on icu_capi, but...

being able to import a small deptree would help his case for using ICU4X

<rant>
Perhaps it was a mistake to put components into separate crates. It was explicitly stated in our 1.0 announcement that ICU4X has few dependencies, even though our cargo tree looks big. If people are afraid to use ICU4X because of the cargo tree size, then perhaps our value judgement was off when we decided to go with separate crates.

IIRC, the only real reason we went with separate crates was to make it more explicit when things depended on other things and make it harder to get into the spaghetti situation like ICU4J. (Crates help with that but aren't a panacea. We could have built separate tooling that looked on a class level, for example.)

In other words, this thread makes it seem as if a decision we made primarily with our own development workflow as the priority is now getting in the way of adoption. That's very bad.
</rant>

[sffc]

Back on topic: how do you feel about the features being limited to icu_capi and NOT icu_capi_cdylib, etc. I'm slightly worried about getting into a situation where there are files named icu_capi_cdylib.so that export different sets of symbols. The cdylib crate doesn't do much and can easily be replicated by clients (they most likely will need to do so anyway).

[Manishearth]

If people are afraid to use ICU4X because of the cargo tree size, then perhaps our value judgement was off when we decided to go with separate crates.

I think this is collapsing the space of potential users into too small a use case space.

Different people have different needs. Some people want "few external dependencies". ICU4X (capi) being a large bundle does defeat that purpose a little bit because some of the ICU4X components have non-ICU4X dependencies. Not much, but a little.

Some people have to deal with vendoring and updates. There the absolute number matters. While I'm certainly in this boat I consider this to be less of an issue overall. Large projects have to deal with this kind of thing and we can try to make it nice but if there's a tradeoff we do not need to prioritize this.

For some people ICU4X itself is rather large. If your goal is experimentation with just, say, normalization, it becomes harder to make your case if you're pulling in a large library than when you're pulling in a small one. The slicing of ICU4X is irrelevant here: it's a problem when you have single large crate and a problem when you have multiple small ones.

It's especially a problem if you have crate audit/review policies where you're supposed to code review all imports.

I think our value judgement was correct, crate number is not that huge a deal. But total size still is, and if we have the ability to be flexible on that angle I think we should.

Back on topic: how do you feel about the features being limited to icu_capi and NOT icu_capi_cdylib, etc.

Fine with that, though perhaps capi_cdylib should do the "disable all features and enable them by default" trick. I don't care strongly, I agree that complex users might want their own entrypoint anyway.

[sffc]

Group consensus is to move forward with this proposal.

LGTM: @sffc @Manishearth @robertbastian