hey all, we’re having what should be the last sync to finalize the ethpmv3 spec tomorrow - 8AM CDT / 9AM EDT / 3PM CEST. would love to see y’all there. i’ll post a zoom link to the eth-magicians forum shortly before start time. https://ethereum-magicians.org/t/ethpm-v3-specification-working-group/4086/21
@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.