@njgheorghita also, we should look into making a big push to get packages published, maybe like a small fund the EF can sponsor to help debug and get teams to publish packages for major dapps (UniSwap, Compound, Maker, etc.). I know you've published a lot yourself, but still we need teams to make this a habit so it becomes self-sustaining.
maybe look into working with OpenZeppelin about creating their own package registry
they're probably the one ecosystem component that deserves their own registry
hahaha those gifs are fire
yeah, it’s been a tricky game of chicken/egg encouraging protocols to adopt ethpm into their workflow (from the ones i’ve talked with, they say there’s little demand for them). i’m leaning towards waiting for a big marketing push until v3 support has landed across solidity/vyper/truffle/brownie… thoughts?
the packaging set up was always an issue for teams in Ethereum
but now with DeFi applications, it's just screaming for attention
the copy/paste the ecosystem has adopted as best practices (or worse, installing via NPM) is just atrocious
@chriseth no worries, there’s no big rush. I’m aiming to have the draft for the erc up early next week - but even then while it’s in draft status we can still make any needed adjustments
thankfully, I think the ETH 2.0 testnets are engendering some Goerli adoption
@njgheorghita "until v3 support has landed across solidity/vyper/truffle/brownie…" and Mamba (https://mamba.black). I'll add support for EPM in this week. I'll read v3 tomorrow and share my thoughts (if I have any).
I have implemented a preliminary support for EPM in Mamba. https://mamba.black/documentation/using-ethereum-package-manager/
I need to add more stuff: better creating manifest tool, creating registry support, etc.
After working on these stuff for a couple of days, then I started to understand EPM. I'll read v3 again with fresh eyes.
I need to add more stuff: better creating manifest tool, creating registry support, etc.
After working on these stuff for a couple of days, then I started to understand EPM. I'll read v3 again with fresh eyes.
Btw, https://ethpm.com/ gives security threat warning. But not https://www.ethpm.com.
or should we just not handle that
Sorry, by the way, did still not get around to implementing it...
that's a valid SPDX identifier
right now, we just take the whole text field and write it as a text field in the EthPM output
we could process it and try to return it in a series of brackets to try and express
AND and OR, but that seems like overkill
yup, i’d agree that it’s overkill. the ethpm spec only defines a license field for the entire package. however, if an individual file source declares it’s own license, that takes precedence over the package-scoped license. I feel comfortable keeping it simple and identifying the license as a text field, leaving the responsibility up to the package author to ensure that multiple licenses are compatible.
alright, but still this leaves the opening for what happens when individual files define there own. I propose:
- top level
licensefield in the manifest (text field, optional, and can be empty) licensefield in each contract source file (text field, optional, and can be empty)- it is up to various end users of manifests to define how individual source file licenses "extend" the top level, but in general there is an acknowledgement that it does indeed "extend" whatever the top level specifies
the handler would have to parse for SPDX combinators and determine
AND or OR "extension" (if necessary, probably AND) and also determine if a license conflict exists during audit
(
npm audit does license conflict checks)
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.
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 isThe 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:
- The file-specific license extends (via either
ANDorOR) the project-wide license - The file-specific license replaces the project-wide license
(2) is probably simpler and easier if we want to define it in the standard
For (1), this leaves it open to more interpretation
I agree that (2) is probably best
yeah, that's a miss. it's defined here as being optional: https://ethpm.github.io/ethpm-spec/v3-package-spec.html#license-license, but SourceObject does not define it as an optional member: https://ethpm.github.io/ethpm-spec/v3-package-spec.html#source-object
It was my understanding from the last time we talked about licenses (which I believe was the soldity summit) was that the ethpm spec would only officially define the package-wide
”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).
On one hand, it would be very simple to officially define a
”license” field for a SourceObject. On the other hand, this introduces complexities regarding which license takes precedence as @fubuloubu elaborated upon.