dojo icon indicating copy to clipboard operation
dojo copied to clipboard

Integrating Sozo with asdf

Open kronosapiens opened this issue 3 months ago • 4 comments

Closes DOJ-943

Is your feature request related to a problem? Please describe.

Last month, we introduced asdf plugins for the Dojo toolchain -- Sozo, Katana, and Torii. Asdf is a popular version-management tool and is already well-integrated into the Cairo ecosystem. Compared to our current dojoup version-management tool, asdf has enhanced support for programmatic version management through their .tool-versions file.

Given the tight integration of asdf in the Cairo ecosystem, and the superior version-management functionality provided by .tool-versions, we should consider enhancing our support for asdf through Sozo, making Sozo the primary entrypoint for Dojo version management.

This enhanced programmatic management both improves the developer experience for end-users, and opens up new possibilities for integration testing and and improved release process by simplifying compatibility testing across the Dojo stack.

Describe the solution you'd like

We should explore adding additional commands to Sozo for reconciling various versions of the toolchain. Leveraging the versions.json file in this repo, Sozo can be made version-aware and can help users validate and update their toolchain versions. Some possible examples:

sozo install # Writes the latest toolchain versions to `.tool-versions` and calls asdf install

sozo install 1.7.0 # Writes the specified toolchain versions (as per `versions.json`) to `tool-versions` and calls asdf install

sozo validate # Checks the current `.tool-versions` against `versions.json` and warns the user about compatibility

These are just some ideas; open to other suggestions / feedback / discussion.

Describe alternatives you've considered

An alternative would be to continue prioritizing dojoup as the entrypoint for Dojo version management. The advantages of sticking with Dojoup are the continuity with past practice, and the potential higher level of control over the developer experience by owning the entire version management process.

On balance I would not recommend this, as it becomes harder to leverage improvements in asdf and introduces an additional maintenance burden.

Additional context

Here are the implementations for the asdf plugins:

https://github.com/dojoengine/asdf-katana https://github.com/dojoengine/asdf-sozo https://github.com/dojoengine/asdf-torii

kronosapiens avatar Sep 11 '25 14:09 kronosapiens

Thank you @kronosapiens for taking the time to write this.

I do agree that we should move to a more globally adopted solution, and reduce maintenance of custom software.

Having Sozo capable of detecting the installation and the different component of the chain it has to work with is a good idea.

Like so, one could simply install Sozo via ASDF, and then have the other tools automatically installed with Sozo.

We could even have sozo migrate doing some stuff automatically if it detects that the targeted network is localhost, and installing Katana.

Sozo never interact directly with Torii, but it is still a good thing if all the components are actually there.

If we go with a Sozo command, I would suggest having sozo toolchain install/validate to clearly scope the functionality, WDYT?

Keen to see what other are thinking about that.

glihm avatar Sep 11 '25 15:09 glihm

I like the idea of having sozo toolchain as the entry point for this functionality, and then having other subcommands past that.

We could also update the install script to install only asdf-sozo and then call sozo toolchain install instead of installing all three asdf-* plugins directly.

kronosapiens avatar Sep 11 '25 16:09 kronosapiens

Can I work on this, please?

lucifer1017 avatar Sep 15 '25 17:09 lucifer1017

Can I work on this, please?

we are still defining the behavior, what are you thoughts on the current discussion?

glihm avatar Sep 17 '25 16:09 glihm