Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Nick Gheorghita
    @njgheorghita
    @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

    El De-dog-lo
    @fubuloubu

    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:

    1. The file-specific license extends (via either AND or OR) the project-wide license
    2. 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
    chriseth
    @chriseth
    is this the latest spec https://ethpm.github.io/ethpm-spec/v3-package-spec.html ?
    chriseth
    @chriseth
    hm, it does not seem so since it does not contain per-file licenses
    El De-dog-lo
    @fubuloubu
    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
    chriseth
    @chriseth
    so it should be the latest version?
    Nick Gheorghita
    @njgheorghita
    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.
    If i’m reading the room correctly, consensus is now that we should define both a ”license” field in the top-level ”meta” object and a SourceObject (which I can update shortly)?
    chriseth
    @chriseth
    the solidity compiler will use the newly introduced license comments to add a license to each source file individually. How that relates to the whole package has to be determined my a human, I would say. So the fields "package license" and "license of an individual file" are two different things, even when they are related
    also it can be rather common that libraries have a different license than the project using the library, so it would make sense to have a granularity at the file level
    El De-dog-lo
    @fubuloubu

    If i’m reading the room correctly, consensus is now that we should define both a ”license” field in the top-level ”meta” object and a SourceObject (which I can update shortly)?

    yes, and to make it simpler, a SourceObject license overrides the project-wide one

    so if you want it to extend, you have to do it manually
    chriseth
    @chriseth
    while implementing, I found another minor issue: We also support compiling starting from a previously exported AST, without a source file. I think this can be solved by supporting more than just 'solidity', 'vyper' and 'abi-json' as file type, but I have not done this yet
    so I would maybe use something like 'soliditiy-ast-json'
    El De-dog-lo
    @fubuloubu
    @chriseth what's the use case for that?
    also, @axic did you ever end up making an ABIv2 ERC?
    chriseth
    @chriseth
    @fubuloubu you can output the ast, modify it and "recompile". One of the use-cases is mutation testing.
    Nick Gheorghita
    @njgheorghita
    @chriseth As of now the spec states that for the 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
    chriseth
    @chriseth
    yeah, abi-json is probably a better name. Thanks!