”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.
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:
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!