”meta” license. Leaving it up to individual tooling / frameworks to decide if they want to include a license for a SourceObject (eg. solc metadata including ”license” in a SourceObject would still be a valid ethpm package).
”license” field for a SourceObject. On the other hand, this introduces complexities regarding which license takes precedence as @fubuloubu elaborated upon.
”license” field in the top-level ”meta” object and a SourceObject (which I can update shortly)?
type of a source file, The field **should** be one
of the following values: “jsonabi", “solidity", “vyper".I interpret this as the list is non-exhaustive, and any string is a valid type, but I’m happy to include solidity-ast-json as one of the suggested types if you give a :thumbsup: - also I can update ”jsonabi” to ”abi-json” if that is the preferred identifier.
@fubuloubu thanks for helping think this through, the update is in ethpm/ethpm-spec#155
awesome!
istanbul, constantinople, etc.
Has this topic survived or has that ever been discussed again after?
contractTypes in a manifest should reference source files in the same manifest, not from a dependency. IMO since all source files are stored on some content-addressed network, then it should straightforward to reference the content-addressed (ipfs / swarm / etc) urls from the authors manifest in a “deployment descriptor” type manifest.
Thanks, @njgheorghita and @chriseth!
If I followed the development of the ethpm standard correctly over the years, this scenario is still supported by the current standard, just that the same manifest format is used for both: a more "source-oriented" manifest as well as a "deployment" manifest. Example:
- Author/project releases package A with manifest, does NOT deploy it on any chain, so posts a manifest and package to IPFS that just describes the source content and other packages required to compile
- A consumer project wants to leverage package A in their project X and creates another manifest when compiling and deploying (let's say, to their test chain or a permissioned Besu chain). This creates the manifest containing the addresses of deployed contracts since the original author obviously was not able to provide a manifest that combines the source metadata and the specific addresses for this project's deployment reality.
The problem (or inconvenience) I see is that the deployment manifest would need its own name or version, right? Project X would basically take the published package A (v1.2.0) and create a manifest for their deployment on their particular chain and have to call it package A (v1.2.1) or rename the package. Even though the original package has not changed, a new manifest with new name and version number is needed, just to include the deployed addresses of that package.
If my understanding here is incorrect, I'd appreciate a pointer. Coming from an enterprise background and with permissioned EVM chains being more wide-spread now, I've struggled to understand how exactly this scenario would look like.
Ultimately, the spec is designed to be as flexible as possible, to suit any use case. In version 3, we no longer strictly require that every package contains a name and version. However, it’s suggested since those are useful identifiers. But, it’s perfectly reasonable to release a manifest json that doesn’t contain name and version fields onto any registry under any given name and version.
However, I’m a little confused by this sentance Even though the original package has not changed, a new manifest with new name and version number is needed, just to include the deployed addresses of that package.. If you are adding deployments (addresses, txhashes, etc..) to a “source” package, isn’t this inherently more than just adding a new name and version, and wouldn’t you anyways want a new name and version to identify the newly added deployments? But, maybe I’m not understanding your use case exactly...
phew, this is a hefty piece of a document…
it certainly is! many thanks to you and bryant for the reviews!