ethPM V3 Specification Working Group

I’m really not sure if this forum-style discussion is the best way to do this

What’s the best place to do so? Let’s move it there. It’s possible to separate some questions into issues, but IDK where to put them.

If there are multiple contract types specified - is there a way to provide the “main” contract in some way?

I think it’s reasonable to define default keyword in Solidity to specify it explicitly. It would help to export things with automated tools. Libraries authors usually define single contract per file, but it’s only an agreement and it’s not certain for all libraries. Export such a contract as the main one doesn’t seem correct due to this uncertainty.

Is the idea to give users the choice about what kind of information they choose to provide about the compilation?

@gh1dra The compiler field is for information about the compiler and its settings that were used to generate the outputs (abi, bytecodes, userdoc, devdoc) rather than containing the outputs of the compilation. As you said, this gives the user more flexibility in choosing what fields they want or are able to include in a manifest.

I’m fine with breaking Solidity metadata with regards to “version” if it is a dealbreaker for EthPM

It’s not a dealbreaker for me, but I do prefer the scheme ("manifest", "name", "version") that @rumkin proposed the best. It’s the cleanest / easiest to understand.

as long as it is still possible to easily determine whether the given json is a v1 Solidity metadata json.

If we adopt this scheme, I’m not so sure this will be easily achieved. As @fubuloubu pointed out, there will be ethpm v1 & v2 manifests that have a "version" field of "1" (referring to the version of that specific package release, rather than the specification it conforms to). These will be impossible to simply distinguish from v1 Solidity metadata json (which also have a "version" field of "1"). Unless the tooling has the knowledge to search for a "manifest" field (required in all ethpm v3 manifests), validate that it is "3" - and then it will be able to distinguish b/w the two specifications. So it is possible reliably determine which specification a json object is, but it won’t be trivial. If this is an acceptable amount of complexity for @chriseth, I’ll update the spec to reflect this change.

I would also prefer camelCase.

:+1: I’m also ok with this change. Unless any of the python/vyper ppl have strong objections, I’ll update the spec.

sources: " Paths must resolve to a path within the current virtual directory." - do we really need this requirement? What does it mean for a path to resolve to such a path?

For ethpm, we need the ability to faithfully recreate the original source tree. Otherwise, when users “install” a package to disk - if the paths are not the same paths of the original source tree, then they might not be able to re-compile the sources.

In ethpm v1/v2 we required all paths to be relative paths that begin with ./ (the root of the virtual directory), which has worked well. Though, I understand the solidity compiler might not want to enforce such a requirement. If we relax this requirement, we’ll need to define an additional mechanism (like a filesystem key) that maps the paths used to valid filesystem paths - which will be required for packages to have the capability to be written to disk (“installed”).

How do you determine if it resolves to a directory or to a file?

If the path points to a content-addressed uri, the uri must be resolved to determine whether it’s a directory or a file. The only other option is for the path to point to an inlined string of the source contract which would always be a single file.

If there are multiple contract types specified - is there a way to provide the “main” contract in some way? For Solidity metadata, there is exactly one contract type that is the one currently being compiled. Is the expectation that in this case, there is only one item in this object?

Yup, that’s how I’d see it working out.

contract alias: In the Solidity compiler, we identify names by prefixing the file name (including path) followed by a “:”. How do contract aliases identify the actual contract in the source?

In ethpm a contract alias is defined as <contract-name>[<identifier>]. In ethpm v1/v2 there was no mechanism to map a contract type to a source - however in v3 it seems to me as though the compilationTarget field in the compiler settings would serve this function.

Why is the compiler a sub-field of the contract type? I see that different compilers could be used for different contract, but in that case, shouldn’t the sources also be a sub-field of the contract type?

I’m not sure I understand this concern exactly. There are packages that would be useful with just "sources" and no "contract_types". Also, different compilers could be used to generate different "contract_types" for the same source. This would introduce a lot of redundancy if sources were located in "contract_types".

I’m really not sure if this forum-style discussion is the best way to do this

Agreed, I’m starting to think that it’s time to move this to github, where we can have more nuanced threads around specific concerns. I’ll work on migrating the changes discussed here to the ethpm-spec repository - and link it here once it’s updated.

1 Like

Can we just schedule a call tomorrow or on Thursday and settle most of the questions in on hour? :slight_smile:

1 Like

Good call - let’s aim for 9AM CST / 3PM CET on Thursday. It’s flexible so if anybody would like to join but has a conflict - we can adjust the time as needed. I’ll post a zoom link here a couple minutes before the time we settle on.

1 Like

Here’s the zoom link for the call taking place in about 5 minutes

Updated zoom link

Thanks for the call, that was very insightful!

During the call, ben was briefly talking about importing interfaces through their JSON-ABI as an interoperability measure. The relevant issue in the Solidity repo is here: https://github.com/ethereum/solidity/issues/1687

A comment by alex suggests to put these abi-json interfaces in their own files in the standard-io-input (as part of the “sources” field) and add a “kind” field for each source file where this would be something like “abi-json”.

This “kind” field would also make it easier for projects spanning multiple languages.

1 Like

For interfaces import I’d suggest to have an ability of file import, like so:

interface Token from './erc20.json'

And for JSON files with custom structure it’s possible to define a path inside of JSON:

interface Token from './erc20.json#contracts[0].abi'

Where ./erc.json is a path to ABI file and #contracts[0].abi is a path inside of JSON object. It uses some trick as URL suppose hash wouldn’t be sent with a request and should be handled on the client, it’s safe to use hash in paths like so. And handle it with solidity compiler itself.

@rumkin I’m not hugely familiar with how the solidity compiler handles imports - but this seems a little out of scope for the ethpm v3 specification. I could be wrong though, so feel free to bring this up at the next sync.

Hey Guys! Hope everyone’s well.

The ethpm docs now reflect the changes we’ve discussed. http://ethpm.github.io/ethpm-spec/

There is now a machine-readable schema to validate v3 manifests - it can be found under spec/v3.spec.json in the ethpm-spec repo.

The examples in the ethpm-spec repo have been updated to reflect the changes in the spec - for a visual idea of what v3 packages might look like. You can find them under their respective folders under /examples/ with the file name v3.json @ https://github.com/ethpm/ethpm-spec

This spec is still a WIP - though we’ll be trying to finalize it within the next sync or two - so the sooner we get any suggested changes, the better. To give everyone enough time to go over the changes / examples, let’s plan our next sync for Thursday, April 16 - at 9AM CST / 3PM CET. If that time doesn’t conflict with anybody, I’ll post a zoom link here shortly before. Cheers!

2 Likes

Here’s the link for the sync in 5 minutes.

Just a heads up, if you’re not already attending the solidity online conference. There’s going to be an ethpm discussion tomorrow at 8:55 pm central european time. The conversation will revolve around ethpm devx and the v3 technical specification. If you can make it, it’d be great to see everyone there!

https://interspace.solidity-summit.ethereum.org/

Hey all - to continue with the discussion from today’s solidity summit we’ll have a call next Thursday, May 7 at 9AM CST / 3PM CET. I’ll post a zoom link here shortly before.

1 Like

General friendly reminder / ping about the sync tomorrow. It should be the last sync before finalizing the v3 spec! Hope to see y’all there - i’ll post the zoom link here shortly before start time.

Sorry for any confusion, my timezone math was off. Correct times for the sync: 8AM CDT / 9AM EDT / 3PM CEST

sync link: https://us04web.zoom.us/j/73933580804?pwd=Q3MrSDUwd2IzUVZLSUs2VDJuMnpkdz09

Would you consider this a “last call” at this point? I will Tweet something out to see if there are others who would like to submit feedback.

2 Likes

Yeah, @njgheorghita would it be possible to draft a blog post about this so we can Tweet it out and get Last Call comments on it before you draft the EIP?

1 Like

Yeah, that would be excellent. Tweet blasts are much appreciated as my twitter game is pretty weak. I’ll type it up and link it here as soon as it’s ready.

2 Likes

ping @fubuloubu @jpitts. I wrote up a short outline of the proposed v3 changes here - thanks for the blast!

Let me know if I forgot something or got anything horribly wrong.

I’m also proposing a spec freeze date of May 18 - which can be delayed if there are any problems found.

2 Likes