it is up to various end users of manifests to define how individual source file licenses "extend" the top level. I’m by no means a lawyer so I could be wrong, but to me, it seems like the spec should at least address best practice for packages that have licenses defined in the top-level
”meta”object, and for individual sources. Which, as of now is
The license field declares the license associated with this package. This value should conform to the SPDX format. Packages should include this field. If a file Source Object defines its own license, that license takes precedence for that particular file over the package-scoped meta license.
So we have two options:
OR) the project-wide license
”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)?
typeof 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-jsonas one of the suggested types if you give a :thumbsup: - also I can update
”abi-json”if that is the preferred identifier.
contractTypesin 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
version. However, it’s suggested since those are useful identifiers. But, it’s perfectly reasonable to release a manifest json that doesn’t contain
version fields onto any registry under any given
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...