Open fubuloubu opened 6 years ago
👎
Requiring source adds bloat to packages which are intended for use cases where package verification is not a requirement. Specific use case for this would be a private chain which uses a private package registry with packages that are all explicitly trusted. In this case an organization should not be required to include the package source in their packages.
Another use case for the public chain is the cryptokitties contract which does gene splicing. The source code for that contract is intentionally left unpublished so that the exact algorithm for gene splicing is kept private.
That is a great point. 💯 agree
Optional then? I would have a problem in the current examples linking the contract to the source without doing the compilation myself or analyzing each source.
I'd support adding an optional souce_path
to the contract_type
. It'd serve as a helpful hint and should be easy to validate when recompiling.
+1 on adding source_path
to the contract_type
.
E.g. I want to only get the swarm/ipfs
source file that I need and not the entire package in case I want to see/test a specific contract.
I'd like to point out that without analyzing the source file, it's non-trivial to know if you've got everything you need since a "Contract" can span multiple files (depending on the language you are working with).
I believe
"source":"./contracts/AbstractToken.sol"
should be a mandatory sub-key of a "ContractType" object underneath the "contract_types" object. This way I can do a 1-to-1 match of the contract to the file that created it (and also find it's source on IPFS through the "sources" key).I personally like that "contract_types" does NOT use the full file name e.g.
"/path/to/Contract.sol:Contract"
. The contract's name in the package namespace should not be allowed to be duplicated (solidity does this), and this enforces that by default.