Are you sure that is actually random? Did it happen locally or on a testbot?

I had that as well locally and I've also had troubles with similar tests in DependencyTest.

Somehow the order is different for me locally, the only way to get that to pass (It was in the issue that made node.module optional I think) was to go after the order that the testbots were getting and ignoring local test fails.

We need to fix it either way, just trying to identify the actual problem. I was wondering if it is 5.5, but alexpott is also running 5.5 and he wrote those tests...

We should still looking into improving this however, and possibly make the test use modules that have a direct dependency chain within themself so that the order remains stable? We're right now testing if two modules without any relation to each other (or any other module, because neither of them have any dependencies or have anything depending on them) are installed in the same order, but given their dependency situation, that order is really irrelevant?

Definitely +1 to adding a comment here. However, let's be more explicit so it's more clear how and why we are using array_multisort(). Reading this, I wouldn't know not to switch back to an arsort(). @sun suggested expanding the comment to more clearly document the intended sorting algorithm, and linked ExtensionDiscovery.

As written above, I think we should be using modules that have direct dependencies between them.

We're testing an order where there is none, action and ban have no relation to each other and there is no need for them to be in a specific order, that's why any change in the module list can affect their order.

1. Fixed - added improved docs and move the sorts to protected methods.
2. Not sure how to add a more specific test for this. Essentially we'd need to test that we don't go back to this http://3v4l.org/9suEd but since we don't controller the number of modules Drupal has I'm at a loss.

Re #12 I think it is valuable to have a known order that modules of the same weight will be enabled during a config sync since that might help us catch crazy things - or never see crazy things - but what is less likely to happen is that one one person has a crazy thing happen that is unrepeatable.

This addresses #1 about the comments by making the sorting its own methods. Just an idea about how we can make this array manipulation less terrifying, less regression-prone, and more self-documenting, though honestly it might be better to factor out more of it.

Unless there is a technical use-case/requirement, please remove the separate methods.

Functions and methods exist for re-use of code logic, NOT to document logic. Use inline comments to document non-obvious code logic.

Usage of array_multisort() is perfectly fine (+ congratulations for figuring out how it works :-))

However, every usage of array_multisort() should always be preceded with an inline comment that explains the (intended) sorting algorithm, which, in essence, is a ORDER BY on multiple columns in a multi-row + multi-column result set.

array_multisort() is nothing else than a math algorithm natively provided by PHP core. It's pointless to wrap each call to it into a separate method for documentation purposes only. Based on that logic, you could as well wrap each all to array_diff_key(). No, thanks.

@sun, you misunderstood my comment. I am absolutely in favor of thoroughly documenting the sort order, and that's what both #13 and #14 try to do and what I'm finishing now.

@alexpott and I discussed that the underlying concern here is that determining a canonical sort order for modules based on dependencies isn't the responsibility of the ConfigImporter -- it belongs to the extension system and should be the same everywhere. That's why this fragility cropped up (aside from PHP being silly), that's why the test coverage seems insufficient to me and out of scope to @Berdir, and that's why it seemed wrong for the array sort logic to be inlined that way. So, I'm going to reroll with one inline multisort for uninstallation -- complete with detailed comment explaining the intended sort order -- that is reversed for the install order. Then, we can add a followup to move this functionality to the extension system, which already has internal support for other sorting, as shown in #19.

I think we can move forward here — even though my last question was why we're first sorting reversely and later reverse it again. At least the multisort is harder to understand, as it's very uncommon that you see a module extension list being sorted completely "upside-down".