Multi-layered directory structure

[sffc]

In #18 we decided to make a top-level /components directory. I like this, but I'm also thinking that it might be good to have an extra layer of abstraction. We've come across several types of components so far:

1. Core i18n components: Locale, PluralRules, NumberFormat, etc.
2. Non-i18n utilities: FixedDecimal, Writeable, etc.
3. Data-related code: DataProvider, CldrJsonDataProvider, etc.
4. Data dump (JSON resources)

How should we structure these in the repository?

FYI, ICU4C is split into four categories:

1. common (UnicodeString, UnicodeSet, etc.)
2. i18n (NumberFormat, PluralRules, etc.)
3. io (u_sprintf, etc.)
4. layoutex (deprecated layout engine)

Here's one possible layout, with an emphasis on structure:

• /
  • components/
    • locales/
      • language-info/ (crate)
      • language-matcher/ (crate)
      • locale/ (crate)
    • numbers/
      • fixed-decimal/ (crate)
      • number-format/ (crate)
    • unicode/
      • unicode-set/ (crate)
      • unicode-props/ (crate)
    • udata/
      • cldr-json-data-provider/ (crate)
      • data-provider/ (crate)
      • fs-data-provider/ (crate)
      • fs-data-exporter/ (crate)
    • strings/
      • writeable/ (crate)
  • resources/
    • json/ (root of JSON data directory, latest version)

Here's another possible layout, with an emphasis on flatness:

• /
  • components/
    • language-info/ (crate)
    • language-matcher/ (crate)
    • locale/ (crate)
    • number-format/ (crate)
    • unicode-props/ (crate)
  • udata/
    • cldr-json-data-provider/ (crate)
    • data-provider/ (crate)
    • fs-data-provider/ (crate)
    • fs-data-exporter/ (crate)
    • json-data/ (root of JSON data directory, latest version)
  • utils/
    • writeable/ (crate)
    • fixed-decimal/ (crate)
    • unicode-set/ (crate)

Another, simpler layout:

• /
  • components/
    • language-info/ (crate)
    • language-matcher/ (crate)
    • locale/ (crate)
    • number-format/ (crate)
    • unicode-props/ (crate)
    • cldr-json-data-provider/ (crate)
    • data-provider/ (crate)
    • fs-data-provider/ (crate)
    • fs-data-exporter/ (crate)
    • writeable/ (crate)
    • fixed-decimal/ (crate)
    • unicode-set/ (crate)
  • resources/
    • json-data/ (root of JSON data directory, latest version)

Option 4:

• /
  • components/
    • language-info/ (crate)
    • language-matcher/ (crate)
    • locale/ (crate)
    • number-format/ (crate)
    • unicode-props/ (crate)
    • cldr-json-data-provider/ (crate)
    • data-provider/ (crate)
    • fs-data-provider/ (crate)
    • fs-data-exporter/ (crate)
  • utils/
    • writeable/ (crate)
    • fixed-decimal/ (crate)
    • unicode-set/ (crate)
  • resources/
    • json-data/ (root of JSON data directory, latest version)

Option 5:

• /
  • components/
    • language-info/ (crate)
    • language-matcher/ (crate)
    • locale/ (crate)
    • number-format/ (crate)
    • unicode-props/ (crate)
  • udata/
    • cldr-json-data-provider/ (crate)
    • data-provider/ (crate)
    • fs-data-provider/ (crate)
    • fs-data-exporter/ (crate)
  • utils/
    • writeable/ (crate)
    • fixed-decimal/ (crate)
    • unicode-set/ (crate)
  • resources/
    • json-data/ (root of JSON data directory, latest version)

Thoughts?

@Manishearth

[Manishearth]

I like the slightly flatter one. No strong preference

[zbraniecki]

I moved FixedDecimal to utils/fixed-decimal according to this proposal.

@sffc would you like me to also move all data provider code to udata?

[zbraniecki]

And one more question i have is about the meta-packages. components/icu and components/icu4x and not really components.
No harm in keeping them in, but we could also move them out to crates/* or meta/* (although meta feels like meta data) and then components/* will actually stay only with components.

Last q - in your proposal uniset is not a component. To me it feels like it is. Should I move it to utils?

[Manishearth]

@zbraniecki servo used to have a components/servo, it's fine imo. But no preference.

[sffc]

TBH, I'm still fuzzy on the difference between utils and components.

@sffc would you like me to also move all data provider code to udata?

No; let's adopt Option 4 for now and keep them under components. I could see an argument for moving some of them into utils, but I'm not sure what the advantage is of making a new top-level directory.