I thought the registry was going to the icu crate?

It leads to a circular dependency for the broken-out datagen provider, and it's also pretty inefficient to pull in all of ICU4X just for some tokens.

It leads to a circular dependency for the broken-out datagen provider,

How? icu shouldn't depend on anything in datagen.

and it's also pretty inefficient to pull in all of ICU4X just for some tokens.

The tokens are symbols of the icu crate and can't really be used without including the icu crate.

The tokens are symbols of the icu crate and can't really be used without including the icu crate.

It's entirely feasible to write a datagen script that uses only one subcomponent. It shouldn't pull in all of ICU4X.

Please let me do the refactorings, if we can identify a crate to fold it into after everything is done, Im happy to do that. It might be icu_provider.

How? icu shouldn't depend on anything in datagen.

icu > icu_list > icu_provider_baked > icu. The last link is with the export feature only, but that doesn't matter for circularity.

How? icu shouldn't depend on anything in datagen.

icu > icu_list > icu_provider_baked > icu. The last link is with the export feature only, but that doesn't matter for circularity.

What is icu_provider_baked?

The tokens are symbols of the icu crate and can't really be used without including the icu crate.

It's entirely feasible to write a datagen script that uses only one subcomponent. It shouldn't pull in all of ICU4X.

You don't need the registry; it's mainly useful when you need to branch over all keys markers. But if you need to write a custom datagen script for just a few keys markers, you can just hardcode them.

Please let me do the refactorings, if we can identify a crate to fold it into after everything is done, Im happy to do that. It might be icu_provider.

ok

baked_exporter needs the registry