Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Nick Gheorghita
    @njgheorghita
    let’s try that again...
    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
    El De-dog-lo
    @fubuloubu
    ugh why 9am lol
    Nick Gheorghita
    @njgheorghita
    ahh sorry, just tryna maintain our usual time of 3pm in europe. i’ll push it later for any future syncs
    chriseth
    @chriseth
    @njgheorghita do we have a call now?
    chriseth
    @chriseth
    spdx license comment: https://spdx.org/ids-how
    El De-dog-lo
    @fubuloubu
    @njgheorghita some of your formatting didn't translate from Markdown
    Nick Gheorghita
    @njgheorghita
    @fubuloubu ahh good looks, it’s fixed now, thanks!
    El De-dog-lo
    @fubuloubu
    @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
    Nick Gheorghita
    @njgheorghita
    agreed 1000% percent.
    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?
    El De-dog-lo
    @fubuloubu
    yeah I agree with that, but we really need a good one once v3 is fully supported
    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
    @chriseth
    by the way, I did not have time yet to look ot the full spec
    Nick Gheorghita
    @njgheorghita
    @fubuloubu yea, i’m all on board for a big push
    @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
    El De-dog-lo
    @fubuloubu
    it's like people are in an abusive relationship right now with code sharing -- they don't know that they deserve better
    Nick Gheorghita
    @njgheorghita
    hahaha
    El De-dog-lo
    @fubuloubu
    between that, and everyone using Goerli more (and eventually deprecating Kovan/Rinkeby), it would make Ethereum development so much better
    thankfully, I think the ETH 2.0 testnets are engendering some Goerli adoption
    arjuna sky kok
    @arjunaskykok_gitlab
    @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).
    Nick Gheorghita
    @njgheorghita
    @arjunaskykok_gitlab awesome! let me know if you have any questions
    arjuna sky kok
    @arjunaskykok_gitlab
    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.
    Btw, https://ethpm.com/ gives security threat warning. But not https://www.ethpm.com.
    arjuna sky kok
    @arjunaskykok_gitlab
    Also, in ethpm module (in web3.py library), I saw that HTTP refers to GitHub implementation. Why don't we just name it GitHub because maybe we want to load manifest from real HTTP. Beside that, we also want to support GitLab.
    Nick Gheorghita
    @njgheorghita
    @arjunaskykok_gitlab that’s awesome to hear! and thanks for the heads on on the security warning. I’d agree to change the name for the http backend, I’ll get that implemented in the next update
    El De-dog-lo
    @fubuloubu
    for v3, have we considered what happens when people define multiple licenses?
    or should we just not handle that
    chriseth
    @chriseth
    didn't we say we have a license field per file?
    Sorry, by the way, did still not get around to implementing it...
    El De-dog-lo
    @fubuloubu
    yes, but multiple licenses like Apache-2.0 AND (MIT OR GPL-2.0-only)
    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
    Nick Gheorghita
    @njgheorghita
    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.
    El De-dog-lo
    @fubuloubu
    alright, but still this leaves the opening for what happens when individual files define there own. I propose:
    • top level license field in the manifest (text field, optional, and can be empty)
    • license field 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)
    El De-dog-lo
    @fubuloubu

    ... it does indeed "extend" whatever the top level specifies.

    If it exists and is non-empty

    Nick Gheorghita
    @njgheorghita
    yup, it would be cool to support an ethpm audit feature in the cli (though, i’d be interested to hear your thoughts in how high of a priority this should be?).
    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.
    El De-dog-lo
    @fubuloubu

    yup, it would be cool to support an ethpm audit feature in the cli (though, i’d be interested to hear your thoughts in how high of a priority this should be?).

    very low priority lol