Closed ca11ab1e closed 1 year ago
there is a refactor planned for this part of build cache, but as a workaround it is very easy to pull compilation data from the build manifest. all manifests are EIP-2678 compliant, so you can just do manifest.contract_types["MyContract"]
and have access to the ABI, bytecode, etc. output of the compiler.
Would recommend not assuming anything about the particular layout of the build cache though, you can just create json files as you need them e.g.:
from ape import project
abi_json = project.MyContract.contract_type.abi.json()
+1 to this request as it would make frontend integration, (Typechain), that much easier if each contract had its own ABI in some sort of ABIs folder when ape compiles
+1 to this request as it would make frontend integration, (Typechain), that much easier if each contract had its own ABI in some sort of ABIs folder when ape compiles
The whole project compiles to .build/__local__.json
which is an EIP-2678 compliant ethPM package manifest, containing ABI interfaces and bytecode that can be bundled with a typechain frontend project
this got done
Overview
The current way Ape stores compiled contracts is too Ape-specific. It doesn't ease external use because of it's nature: a big JSON file. It would ease StarkNet devs life if contracts could be compiled to specific files, something like
contract.json
(compiled contract), andcontract_abi.json
(it's ABI). We could then use such files for other stuff, and actually be able to review them more easily. Note that those files are already created bystarknet-compile
, so it doesn't include specific work for Ape, but "just" to use them.It will become even more needed when wanting to deploy contracts to the mainnet where contracts need to be allowlisted: we will need compilation data. And then, we would be forced to move to another tool to just get that data.
Specification
Maybe could we get inspiration from how Protostar does, it's pretty clean.
Dependencies
None.