Closed eternauta1337 closed 6 years ago
+1 to providing a solution to the developers to integrate with zOS in development as part of the MVP, I think that adoption would be infeasible otherwise.
The solution may be simpler than injecting a simulation: an off chain tool could simply query the kernel registry for the code of the proxied contracts, download them locally, and deploy them along with the user's contracts.
"Kernel-land" code can live in any network, i.e.
mainnet
,ropsten
, etc.When developing on a local network such as
development
using testrpc, ganache-cli, or remix's VM, on a dapp or any "User-land" contracts for that matter, there will be no zOS running. This would force developers to work on a public network, which is not only cumbersome for the developer, but contaminating for the network.This is happening to me right now with Basil, forcing me to work in ropsten because this is the only place where we have a KernelProxyFactory for ERC721Token right now.
To address this problem, we should make use of a tool that simulates zOS into the local network, which can be used for local development. This zOS simulation could either mimic the state of another network (eg. mainnet) or be configurable in some way.
A developer's workflow would then be: 1) start a local network using testrpc or ganache-cli, etc... 2) use the zos tool to inject a simulation of zos into the local network 3) deploy development contracts that use/connect with the simulation's zOS contracts