[BUG] Dojo metadata not detected for projects with indirect dependencies

[posaune0423]

Describe the bug

The dojo_metadata_from_package function in crates/dojo-world/src/metadata.rs fails to detect Dojo dependencies for projects that indirectly depend on Dojo through other packages. This causes issues with projects like application project that use Dojo indirectly through dependencies such as protocol that uses dojo.

The current implementation only checks for direct dependencies on dojo or dojo_plugin, missing indirect dependencies and returning default metadata for projects that should have Dojo metadata.

To Reproduce

Steps to reproduce the behavior:

1. Clone the repo pixelaw/app_template
2. run sozo print-env and this just return default value (only RPC URL: http://localhost:5050/)
3. Add dojo = { git = "https://github.com/dojoengine/dojo", tag = "v1.0.0-alpha.11" } to Scarb.toml explicitly
4. re-run sozo print-env, and it output correct metadata

Expected behavior

The dojo_metadata_from_package function should recursively check for Dojo dependencies in all direct and indirect dependencies of a package. It should correctly identify and process Dojo metadata for projects with indirect Dojo dependencies.

Screenshots

None

Additional context

Here, this condition just look at the dependency section in Scarb.toml so can't detect indirect dependency right now.

https://github.com/dojoengine/dojo/blob/069bc1af6c071f10185c758615f80e631938a741/crates/dojo-world/src/metadata.rs#L75-L84

Proposed solutions:

1. Use Scarb.lock instead of Scarb.toml for dependency resolution:

   • This would allow us to see all transitive dependencies, including indirect ones.
   • Implementation would involve parsing the Scarb.lock file and checking for any dojo-related packages.

2. Require explicit declaration of Dojo dependency:

   • Even for projects that use Dojo indirectly, require them to explicitly declare the Dojo dependency in their Scarb.toml.
   • This would simplify dependency detection but might be less convenient for users.

[jancris100]

Can you assign this one to me?

[glihm]

Hey @posaune0423 thanks for this well described issue.

I think in the case you expose here we're in the 2 solution you propose. When you have a package that depends on an other package dojo-dependent, your package must also explicitly use dojo, due to the compiler plugin requirement.

That's the main reason why the parsing was done from the Scarb.toml, so you're right enforcing it should be better in this case. And to enforce, using the Scarb.lock is definitely the easiest way.

@jancris100 you're feeling ok working on that?

[jancris100]

Hello if it's okay, only that I'm on vacations I can start working on it next week

[jancris100]

Hello, I'm already here. Do I work on it?