Thanks! :smile:
if we're standardizing ethPM v3, wouldn't it make sense to have it point to another standard for ABI objects, instead of the Solidity documentation? (which is indirectly pointed to via https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI#json)
let's say there is an ABIv3, then would ethPMv3 point to ABIv2, or would it point to whatever is the latest? Would that make previously compliant ethPMv3 manifests uncompliant?
i’m not sure it’s obvious that’s a case for which the ethpm spec should provision. not being up to date with the possibility of an ABIv3, some questions I’d have are… How likely is it that there will be a v3 & when? And, my greater hope would be that v3 ABIs will be inherently differentiable from v2 - so tooling would be able to recognize each version and treat each ABI accordingly. If that’s not the case, then I’d be inclined to agree that this is something to consider for ethpm v3.
I think it's unlikely at this point, but we also can't tell the future of either of these standards. There's no reliable versioning information that differentiate v1 and v2, so between v2 and v3 it would probably be difficult to tell the difference between them. I think for posterity, there should be an effort to try and formalize ABIv2 (at least) so we don't even have to have these discussions. It seems like a no-brainer that such an important encoding format be standardized in some way.
And the Solidity docs are not the place for it, because it's not an immutable or version controlled display format
I think we tried to get this done last summer, but it never happened.
also turns out it was 2018 that I was remembering :grimacing:
@fubuloubu I’m definitely open to the idea of specifying the abi version in some way, let’s revisit this once #2792 lands
solidity's v1/v2 distinction is less about the standard and more about the implementation
?
@fubuloubu thanks, I wish to have a look at all available preaudited smart contracts to see if they come toughether as building blocks , at least in my mind, to start immagining a project that could catch my curiosity enough to push me to study (i have little time because of family and other company)
hey @bodytexture ! ethpm is currently upgrading from v2 to v3. native support for v3 in truffle should be available within the next couple of weeks. the ethpm-cli (https://github.com/ethpm/ethpm-cli) currently supports v3. to my knowledge, there isn’t a large supply of audited ethpm v3 packages at the moment- we’re hoping that will change once truffle integration and we’ll start to see the more popular projects release their contracts as ethpm packages. if you just want to get a feel for how ethpm works, i’d start with the cli & the docs (https://www.ethpm.com). if you just want to explore audited smart contracts - your best bet is to explore various github repos. if you find this frustrating, tweeting at your favorite protocols that they should release their audited contracts as ethpm packages is a great idea!
@njgheorghita how finalized is v3? specification still says WIP: http://ethpm.github.io/ethpm-spec/v3-package-spec.html
Is there a way to browse packages without writing a script with one of the apis?
@darealsisyphe Hey! That means that you’ll have to sign up for an infura account to get a project id and then set it as the environment variable
WEB3_INFURA_PROJECT_ID. More details on how to can be found here: https://web3py.readthedocs.io/en/stable/quickstart.html?highlight=infura#provider-infura
@carlfarterson was wondering
@fubuloubu Sorry for the misinformation - I was unaware that we have to undergo a
Review phase before Last Call. The spec is currently sitting in Review. There’s an open question on the eth-magicians forum about whether a Checksum should be required for in-lined sources. Once that’s resolved, I feel safe moving onto Last Call (finally :sweat_smile: ). Do you happen to remember why we settled on this requirement during the Solidity Summit sessions?
can you link the forum?
does anyone know how to fix it? i've tried reinstalling libs, didn't help, i guess
btw, error is when i run pip install ethpm-cli
EIP 2678 Will be in
review status for another week or so - and then we’ll bump it to last call. If there are any lingering suggestions / feedback - let’s discuss it here - the sooner the better!
Hi, is there a plan to push ethpm-cli:0.3.0 to dockerhub? It looks like only 0.2.0 is up there currently, and pip has been presenting issues.
I've been attempting to install via pip, with version 21.0.1, and python 3.7.0 (On Ubuntu 18.04), but the installation process seems to be failing from conflicting dependencies. I created a fresh virtualenv for the installation. Also, the install process is quite extended with many messages of the type INFO: pip is looking at multiple versions of <PACKAGE>. When switching to a legacy resolver pip install ethpm-cli --use-deprecated=legacy-resolver, I get this message instead: ERROR: Could not find a version that satisfies the requirement ipfshttpclient==0.7.0a1 (from web3[tester]<6,>=5.13.0->ethpm-cli) (from versions: 0.4.10, 0.4.11, 0.4.12, 0.4.13, 0.4.13.1, 0.4.13.2, 0.6.0, 0.6.0.post1, 0.6.1)
ERROR: No matching distribution found for ipfshttpclient==0.7.0a1 (from web3[tester]<6,>=5.13.0->ethpm-cli)
web3 has an ethpm module you should use