Implicit dependency reordering leads to subpackages not being found

[Mai-Lapyst]

System information

• dub version: 1.31.1, built on Feb 20 2023
• OS Platform and distribution: Arch Linux
• compiler version DMD64 D Compiler v2.102.2

Bug Description

Dub relies internaly onto associative arrays to save dependencies; when now you use some special dependencies, the order in which they are declared in the dub.json file will change in the internal representation, which can lead to errors of subpackages not being resolved correctly:

Example:

"dependencies": {
  "micro_orm": {
    "path": "../"
  },
  "micro_orm:backend_libmariadb" : {
    "path": "../subpackages/backend_libmariadb"
  }
}

Assoc-arrays test-code

void main() {   
    int[string] data_1;
    data_1["minorm"] = 42;
    data_1["minorm:backend_libmariadb"] = 12;
    foreach (k,v; data_1) {
        writeln(k, "=>", v);
    }
    writeln("-----------------------");
    int[string] data_2;
    data_2["micro_orm"] = 42;
    data_2["micro_orm:backend_libmariadb"] = 12;
    foreach (k,v; data_2) {
        writeln(k, "=>", v);
    }
}

Will print:

minorm=>42
minorm:backend_libmariadb=>12
-----------------------
micro_orm:backend_libmariadb=>12
micro_orm=>42

This in turn can lead to VERY misleading errors down the line such as this:

Error Sub package "backend_libmariadb:backend_libmariadb" doesn't exist.

How to reproduce?

1. Download this example project: dub-bug.zip
2. Extract it
3. Run dub build -f inside the test subfolder
4. Get the error mentioned above
5. Change all dub.json files from containing micro_orm to minorm
6. Run dub build -f inside the test subfolder again
7. Compiles sucessfully

Expected Behavior

That either dependency order dosnt change or isn't relevant to correctly getting sub-packages.

Logs

[rikkimax]

Okay taking a look at how this logic work:

getSubPackage is the one erroring: https://github.com/dlang/dub/blob/6080cc5497de5871c6081ab45e66f578e8e3fc74/source/dub/packagemanager.d#L485

It ends up calling: https://github.com/dlang/dub/blob/6080cc5497de5871c6081ab45e66f578e8e3fc74/source/dub/packagemanager.d#L524

What I think is happening is it's trying to do a complete lookup without fully initiating the appropriate package state. Hence this ticket.

The AA behavior is a scapegoat that makes this work accidentally and can be ignored as an unrelated detail to the underlying problem.