[FIX] lbt/bundle/Resolver: Ensure deterministic ordering of raw modules#1208
Conversation
When multiple raw modules share a common dependency, the topological sort tie-breaks by input order. Previously, the input order depended on async resolution timing (pool insertion order), making the output non-deterministic. Now modules are sorted by their filter definition order before topological sorting, ensuring that modules at the same dependency level appear in the order defined by the section's filter list.
|
As long as you don't assume any semantic behind this order (e.g. to compensate for not-declared dependencies), I'm fine with it. IMO, sorting the modules alphabetically would also result in a stable order. |
|
Well, I think there can be cases in which you want a specific order, and sorting alphabetically would break it: Library1 provides 2 raw modules:
Library2 (depends on Library1) provides 1 raw module and owns the bundle config:
Filters in raw section (with
Expected raw-module order:
Maybe I'm missing something, but in this case I do not see a way to ensure that |
|
As I didn't immediately got the point of Matthias' (valid) scenario:
There are other solutions for this problem (e.g. two "raw" sections"). But I agree that retaining the order of the filters as long as dependency order is honoured first, is a much simpler mechanism. |
3 participants
When multiple raw modules share a common dependency, the topological sort tie-breaks by input order. Previously, the input order depended on async resolution timing (pool insertion order), making the output non-deterministic.
Now modules are sorted by their filter definition order before topological sorting, ensuring that modules at the same dependency level appear in the order defined by the section's filter list.