Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    El De-dog-lo
    @fubuloubu
    (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
    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!
    El De-dog-lo
    @fubuloubu

    One of the use-cases is mutation testing.

    Ah gotcha

    @fubuloubu thanks for helping think this through, the update is in ethpm/ethpm-spec#155

    awesome!

    El De-dog-lo
    @fubuloubu
    Have we ever talked about having the EVM version in the package? Is that a thing?
    e.g. istanbul, constantinople, etc.
    chriseth
    @chriseth
    Hm, it could, but I think it is not very straightforward. Ther are two "evm versions" to consider: 1. This bytecode has been compiled for EVM version X, 2. This sourcecode is writter for EVM version Y
    El De-dog-lo
    @fubuloubu
    I think (1) would be most pertinent
    if you have bytecode, and it was compiled targeting a version other than the default for a given compiler version, that's a useful flag to know
    without knowing that, you would be unable to reproduce the bytecode
    (2) is more of a note, I think (1) is the better use case
    chriseth
    @chriseth
    the solidity compiler "exposes" the evm version in the compiler settings flag
    Jan H. Scheufen
    @j-h-scheufen
    @chriseth The topic of EVM version for sourcecode vs. bytecode ^^ reminds me of a discussion we had here with Tim and Piper in the early days of ethpm: That it would make sense to separate the manifest into one for the source code that can be provided by the author/project and describes compile time dependencies and ensures authenticity of the sources. A secondary manifest would be generated as a "deployment descriptor" every time a package's bytecode gets generated, linked with libs and other addresses from a particular chain, and deployed. This second (deployment) manifest obviously can link to the source manifest. It could be provided by the original author (e.g. if he/she deployed the package to mainnet or a test net), but it can also be created (and signed) by anyone making a deployment to any other EVM system that the original author might not care about. This would support enterprise usage of the package system much better as the original source manifest can remain untouched.
    Has this topic survived or has that ever been discussed again after?
    Nick Gheorghita
    @njgheorghita

    the solidity compiler "exposes" the evm version in the compiler settings flag

    :+1:

    Nick Gheorghita
    @njgheorghita
    @j-h-scheufen If i’m understanding correctly, this use-case is possible, but discouraged (aka unlikely to be supported by ethpm tooling). The spec states that contractTypes in 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.
    chriseth
    @chriseth
    I do see the point that "B is a deployment of package A" is something else than "package B is deployed there and package B and package A share the same source"
    But I'm not sure if ethpm should model that and much less how it could model it.
    Jan H. Scheufen
    @j-h-scheufen

    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:

    1. Author/project releases package A with manifest, does NOT deploy it on any chain, so posts a manifest and package to IPFS that just describes the source content and other packages required to compile
    2. A consumer project wants to leverage package A in their project X and creates another manifest when compiling and deploying (let's say, to their test chain or a permissioned Besu chain). This creates the manifest containing the addresses of deployed contracts since the original author obviously was not able to provide a manifest that combines the source metadata and the specific addresses for this project's deployment reality.

    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.

    Nick Gheorghita
    @njgheorghita

    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 name and version. However, it’s suggested since those are useful identifiers. But, it’s perfectly reasonable to release a manifest json that doesn’t contain name and version fields onto any registry under any given name and version.

    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...

    El De-dog-lo
    @fubuloubu

    In version 3, we no longer strictly require that every package contains a name and version.

    This is a good decision because use cases like development frameworks don't strictly need a name/version until it comes time to deploy your package

    Nick Gheorghita
    @njgheorghita
    The EIP for EthPM v3 is here - ethereum/EIPs#2678 . It would be great if anybody has time to give it a review. It was generated from the docs so it should be the exact same as http://ethpm.github.io/ethpm-spec/v3-package-spec.html . A couple reviews would be super helpful, then we can move on to finalizing v3!
    El De-dog-lo
    @fubuloubu
    where's my mention! lol
    just add me below Ben, I like riding on coattails
    El De-dog-lo
    @fubuloubu
    so, thinking about the usecase of having a service like Etherscan verify a contract directly from a Manifest