nile icon indicating copy to clipboard operation
nile copied to clipboard

Add cairo1 compilers

Open ericnordelo opened this issue 2 years ago • 2 comments

This PR enables Nile to compile Cairo1 contracts, generating the corresponding .sierra and .casm artifacts (alongside the extracted ABI).

It is drafted for the reasons listed below:

  1. The Cairo1 compilers are not published to crates.io yet, so as a temporary solution, the binary files were added to the project for testing purposes (compiled for macOS platform). We should update this approach to use the locally installed version after the package gets published.
  2. For the previous reason, tests have not been added to the repository yet (only manual tests have been executed).
  3. The PR is exposing the Cairo1 compilation through a compile-1 command in the CLI. This design was implemented just for testing purposes. We still need to define the API to expose both Cairo1 and Cairo0 compilers in the transition period (with starknet 0.11).
  4. From the fact that we can't directly manage dependency versions for the rust compiler (after published) in Nile (being a python project), I think we should implement a rust crate as a proxy, so we can control what version of the rust compiler Nile will be using, by making it dependant of this crate instead of the compiler directly. If we don't do this, changes in the compiler API can break the Nile integration.

How to test this branch:

  • Checkout to it and run pip install .
  • Copy this hello_starknet.cairo contract as an example inside the contracts directory (or any other directory as you would do with the current compile command).
  • Run nile compile-1 contracts/hello_starknet.cairo to compile it (or change the path accordingly).
  • Check the artifacts inside the artifacts/cairo1 directory (including sierra, casm and abi).

Note that if you are not in macOS, you may need to re-compile the compilers and update them for your platform (in linux this is perhaps not required).

ericnordelo avatar Feb 10 '23 13:02 ericnordelo

  • We still need to define the API to expose both Cairo1 and Cairo0 compilers in the transition period (with starknet 0.11).

Do we? I'm assuming there will be no projects using Cairo0 (c0 for short) and c1 simultaneously. If so, nile 0.13 should be enough for c0 projects, no? And we can remove the cairo-lang python dependency, although that would require a full rewrite of nile as well given how much it relies in c0 python modules.

martriay avatar Feb 10 '23 17:02 martriay

Do we? I'm assuming there will be no projects using Cairo0 (c0 for short) and c1 simultaneously. If so, nile 0.13 should be enough for c0 projects, no?

Right. Then we can keep the same API.

And we can remove the cairo-lang python dependency, although that would require a full rewrite of nile as well given how much it relies in c0 python modules.

Exactly, and being this rewrite probably a considerable effort, I'm leaning toward going for the full refactor in Rust. The main blocker I recognize for this is the stage of the cairo repository itself (documentation and features for starknet), but maybe is currently enough to replicate nile without re-implementing a lot? Should we work in parallel on python and rust versions already?

or simply distribute Nile as a binary/executable without requiring a venv nor pip install that adapts to the new starknet CLI (or Rust modules that replace the current CLI nile depends on)

I think (from thinking quickly) this won't be considerably easier than reimplementing in Rust, so for long-term consistency, I would go for the full refactor. But I'm not sure how much effort will this take, from the current status of the cairo repository.

ericnordelo avatar Feb 13 '23 10:02 ericnordelo