Module order 

Canonical presentation order.

One collection has one order, and every interface that shows it shows that order. A sort written beside a renderer is a second opinion about the same collection, and two opinions drift: the command line alphabetises, the Cockpit groups, the generated index keeps whatever the walk produced, and a reader who compares them concludes that the surfaces disagree about the repository rather than about sorting.

The order is a total order over four parts, most significant first:

1. group — the semantic bucket the item is filed under, itself compared naturally; an item with no group sorts after every grouped item, because an ungrouped tail is legible and an ungrouped head hides the groups.
2. rank — an explicit position inside the group, ascending, for the collections whose domain genuinely has one (a lifecycle runs setup before conclude, whatever those words sort as). It defaults to OrderKey::UNRANKED, so a collection that has no such semantics never mentions it.
3. label — what a person reads, compared naturally: digit runs by value, so item-2 precedes item-10, and letters case-insensitively, so Alpha and alpha stay adjacent.
4. identity — the canonical id, compared naturally, as the final tie-breaker.

The fourth part is what makes the order total rather than merely tidy. Two items with the same label must not exchange places because an unrelated item was added, because a different iterator was used, or because one machine’s filesystem enumerates differently from another’s; identities are unique, so the comparison always ends there.

A numeric sample is ordered here too, by numeric: nobody reads it item by item, but a median read off it depends on its order, and a float has exactly one order worth having.

use majordomus_cli::order::{canonical, OrderKey, Ordered};

struct Recipe {
    group: &'static str,
    name: &'static str,
}

impl Ordered for Recipe {
    fn order_key(&self) -> OrderKey<'_> {
        OrderKey::grouped(self.group, self.name, self.name)
    }
}

let mut recipes = vec![
    Recipe { group: "quality", name: "test-10" },
    Recipe { group: "development", name: "serve" },
    Recipe { group: "quality", name: "test-2" },
];
canonical(&mut recipes);
let order: Vec<_> = recipes.iter().map(|r| r.name).collect();
assert_eq!(order, ["serve", "test-2", "test-10"]);

Structs

OrderKey

The four parts of the canonical order, most significant first. See the module documentation for what each part means and why the last one is not optional.

Traits

Ordered

What a collection’s items answer so that the collection can be put in canonical order.

Functions

canonical

Put a collection in canonical order, in place.

canonical_strings

Put a collection of plain strings in canonical order, in place.

is_canonical

Is this collection already in canonical order? What a validator asks of a projection it did not build, and what a test asks of an interface’s output.

natural_cmp

Compare two human-facing strings the way a person reads them.

numeric

Put a numeric sample in ascending order, in place.

numeric_samples

Put a set of numeric samples in ascending order, in place: value by value in numeric’s order, and a sample that is a prefix of another before it. Once each sample is itself in numeric order, this is what makes a computation that draws among the samples independent of the order they were listed in.