ECS Prep: Decouple config

[epage]

There are two ways of handling config structures

• Give config knowledge of your logic (what we do)
• Give logic knowledge of your config (what we will do)

Changing this is important for switching to an ECS because the structs for the logic are going to be split up.

BREAKING CHANGE: Old-style frontmatter is removed and some config keys
are renamed:

• Sort Order: Asc / Desc were lowercased
• Sass Style: Nested / Expanded / Compact / Compressed were lowercased
• Pagination: All, Tags, Categories, Dates were lowercased

[Geobert]

Give config knowledge of your logic (what we do)
Give logic knowledge of your config (what we will do)

Can you explain the difference please? I don't get it :-/

Also, why another crate for the config, one thing I didn't like about Zola was the multiple crates arch, it means more Cargo.toml to maintain

[epage]

So cobalt used to have the Config also be Builders for the processing logic. The problem with that is how I'm splitting up the processing logic. So now instead the configs are standalone and the processing logic takes the Config as inputs so I can refactor the processing logic without touching the config.

Also, why another crate for the config, one thing I didn't like about Zola was the multiple crates arch, it means more Cargo.toml to maintain

I don't know if this will continue long term. In part it is an experiment to see if a "low deps" crate will be useful for external tools hat manipulate your site. Otherwise, it really is a bookkeeping thing to make it easier for me to experiment. I was able to iterate on and test my config logic in isolation, deferring migrating cobalt. It also let's me track re-licensing.

[epage]

Also, why another crate for the config, one thing I didn't like about Zola was the multiple crates arch, it means more Cargo.toml to maintain

I'm curious, in what way do you find it more work to maintain more crates? There is effort in the initial split but after that, with cargo-release, it seems to be just about the same level of effort to me.

[Geobert]

I'm curious, in what way do you find it more work to maintain more crates? There is effort in the initial split but after that, with cargo-release, it seems to be just about the same level of effort to me.

I wanted to work on tera to add something to zola and I was wondering which subscrate needs to point to my local version of tera. The maintainer told me to changed them all, it's what's he's doing anyway

[epage]

I wanted to work on tera to add something to zola and I was wondering which subscrate needs to point to my local version of tera. The maintainer told me to changed them all, it's what's he's doing anyway

So yes, shared dependencies in public APIs do need to be updated in each crate.

However, when I've looked at Zola, it looks like they have less separation of their layers. For example, I find it unusual that the config crate depends on syntect.

The other thing in cobalt's favor is I don't plan to split up cobalt into as many crates. Currently, I'm only looking at config, model, and bin.