Manifest generation on demand

[glihm]

Is your feature request related to a problem? Please describe.
The manifest is a file that is generated by sozo once the world has been migrated. The manifest contains all the resources (contracts/models/events) that have been deployed, the addresses, class hashes and ABIs.

However, currently the manifest if only generated one the world is migrated. Which implies that it can't be generated for a world already migrated.

An important thing to mention is that, in dojo, all addresses are deterministic, based on two values:

1. The class hash of the world (which is directly linked to the Dojo's version).
2. The seed chosen by the user in the dojo_<PROFILE>.toml.

Describe the solution you'd like
The purpose of this issue is to discuss what could be the best approach to access the manifest on demand.

Here are the considerations:

1. If the manifest is generated, but something goes wrong during the migration, the manifest will not represent the actual onchain state of the world. But rather the "what would be" state, if migration is completed.
2. Generating the manifest on demand is possible using the two values described earlier, and before a sozo plan command was used. Currently sozo has the sozo inspect commands which actually pulls from the chain everything that is required to generate the manifest. We may add a sozo inspect --output-manifest /tmp/manifest.json option?

Additional context
The manifest data are defined here:

dojo/crates/dojo/world/src/diff/manifest.rs

Lines 16 to 21 in baf0ce9

	pub struct Manifest {
	pub world: WorldContract,
	pub contracts: Vec<DojoContract>,
	pub models: Vec<DojoModel>,
	pub events: Vec<DojoEvent>,
	}

[knownasred]

I think a variation of 2 would be a great option.

The manifest is now used for more than just storing the current state of the migration for comparison with the hoped state, it is also a way to provide information for the different SDKs (dojo.js)

It is also used for many scripts to extract the addresses of specific contracts: https://github.com/search?q=manifest_dev.json++%7C+path%3A*.sh&type=code&ref=advsearch

Generating the post-migration state is not useful for the use-cases defined above, and I am not convinced that using a command that can alter global state to modify local (on your computer) state is a good idea.

For the second solution, I would argue not to write the manifest to disk, but instead add a variant of --output-format json that would write the expected state to stdout in JSON format.
By using stdout, you reduce steps needed for scripts, by only requiring a pipe to jq, instead of managing temporary files.

[glihm]

Thank you @knownasred for the comments here, let's move to that direction then.

About the output option, where does it make more sense to you?

Should it be using sozo inspect? Currently, sozo inspect is by default using the manifest. And if the manifest is not found, it fallback pulling data from the chain.

Technically speaking, when we run sozo build, we should be able to have all the information too. We could also think about moving the manifest output on build? But it makes it heavier as sometime we don't want to have the whole setup just to have a manifest.

IMHO, having sozo inspect --output-manifest which as you mentioned outputs the JSON to STDOUT could be the less intrusive and easiest way to get a manifest from a project without having anything to build.

sozo inspect is profile based too, so pulling different manifests will be as simple as adding --profile option to the sozo inspect command.

# Default profile
sozo inspect --output-manifest

# Sepolia
sozo inspect --output-manifest --profile sepolia

What are you thoughts around that?