Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stabilize PM module #1125

Merged
merged 24 commits into from
Jan 22, 2019
Merged

Stabilize PM module #1125

merged 24 commits into from
Jan 22, 2019

Conversation

njgheorghita
Copy link
Contributor

@njgheorghita njgheorghita commented Oct 25, 2018

What was wrong?

Stabillize pm module.

How was it fixed?

web3.pm.PM - Main class for interacting with on-chain registries.
web3.pm.ERCRegistry - Base class for subclasses to inherit from that target specific implementations of an ERC-compliant registry.
web3.pm.VyperReferenceRegistry - Class to interact with deployments of the Vyper Reference Registry implementation
web3.pm.SolidityReferenceRegistry - Class to interact with deployments of the Solidity Reference Registry implementation.

Cute animal picture

image

@njgheorghita
Copy link
Contributor Author

@carver @pipermerriam ping for final review - sorry about the massive pr, though the vast majority of this pr has already been approved in prior pr chunks.

@carver, i'm not sure the best way to resolve core-eth_abi2 failing builds failing in circleci.
it seems as though force reinstalling eth-abi-v2 in that tox env is causing problems with the pytest-ethereum plugin (which depends on web3 with eth-abi>=1.2,<2 installed) any thoughts on how to resolve this? the error resolves when I remove all web3 dependencies from pytest-ethereum but of course then, pytest-ethereum is fairly useless and breaks.

@carver
Copy link
Collaborator

carver commented Oct 28, 2018

tox env is causing problems with the pytest-ethereum plugin (which depends on web3 with eth-abi>=1.2,<2 installed) any thoughts on how to resolve this?

pytest-ethereum should probably add support for eth-abi v2-alpha.

How much is pytest-ethereum being used? If it's only a couple places, maybe it's fastest to just drop it and locally replace any missing utilities until it has support for eth-abi v2-alpha.

docs/web3.pm.rst Outdated Show resolved Hide resolved
tests/core/pm-module/conftest.py Outdated Show resolved Hide resolved
tests/core/pm-module/conftest.py Show resolved Hide resolved
tests/core/pm-module/test_ens_integration.py Outdated Show resolved Hide resolved
tests/core/pm-module/test_ens_integration.py Outdated Show resolved Hide resolved
tests/core/pm-module/test_ens_integration.py Show resolved Hide resolved
tests/core/pm-module/test_ens_integration.py Show resolved Hide resolved
@njgheorghita
Copy link
Contributor Author

@carver It seems that I'm blocked on updating pytest-ethereum and ethpm to work with eth-abiV2 until a web3 version is released which is dependent on eth-abiV2 (currently web3's eth-abi dependency is "eth-abi>=1.2.0,<2.0.0", - Any idea of when I can expect a web3 release with an eth-abiV2 dependency?

@carver
Copy link
Collaborator

carver commented Nov 28, 2018

Any idea of when I can expect a web3 release with an eth-abiV2 dependency?

It first glance, I think that change is backwards compatible (a project that depends on web3 v4 might also depend on eth-abi v1). How about a v5-alpha.0 release?

@njgheorghita
Copy link
Contributor Author

How about a v5-alpha.0 release?

@carver That'd be great! It's no huge rush though, whenever it's ready is fine

@njgheorghita
Copy link
Contributor Author

njgheorghita commented Jan 17, 2019

@carver re: comment above, I'm torn between the two

  • adding PM as a default module on web3 - making it easier for the user to use, but being restricted to no backwards incompatible changes until web3 v6
  • leaving PM off web3 by default - forcing the user to attach PM to their web3 instance, but having more flexibility with the api while still in web3 v5

But, I'm leaning towards the latter option for now as it seems possible the API might change in the near future (especially as collaboration with the other pm teams is picking up). And the attach line is more just annoying than an actual impediment to use.

@pipermerriam
Copy link
Member

As discussed in this morning's stand-up, I'd advocate for requiring explicitly enabling this API for now before we commit to stability.

w3 = Web3(...)
w3.enable_unstable_package_management_api()  # handles the attaching

"`w3.enable_unstable_package_management_api()` and try again."
)

def enable_unstable_package_management_api(self):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question from the peanut gallery... do you think it would be useful to have a disable function too? Or I guess you can just ignore features and/or detach if someone decides they actually don't want to use the features?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not inclined to implement a disable API as they could just re-instantiate their Web3 instance.

Copy link
Member

@pipermerriam pipermerriam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code in tests/core/pm-module/conftest.py looks potentially useful and might be a nice API to have available via web3.tools.pm as a public API (eventually) to allow people to easily setup a registry on a test chain.

docs/web3.pm.rst Outdated
.. autoclass:: web3.pm.PM
:members:

.. note:: If you want to implement your own registry and use it with ``web3.pm``, you must create a subclass that inherits from ``ERCRegistry``, implements all the methods defined in ``ERCRegistry``, and manually set it as the ```registry`` attribute on ``web3.pm``.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like something that would be worth putting in it's own section and 1) explaining why someone would want to do this and 2) how they would do it with a code example.

If the code example isn't something you want to maintain or you don't see it as very useful then maybe just state that replacing the registry is beyond the scope of this guide.

VyperReferenceRegistry,
)

VY_PACKAGE_ID_1 = b'\xd0Y\xe8\xa6\xeaZ\x8b\xbf\x8d\xd0\x97\xa7\xb8\x92#\x16\xdc\xb7\xf0$\xe8"\x0bV\xd3\xc9\xe7\x18\x8ajv@' # noqa: E501
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be nice to represent these as their hex values like:

VY_PACKAGE_ID_1 = to_bytes(hexstr='0xd0...')  # noqa: E501
...

As those values are easier to visually parse.

SOL_RELEASE_ID_4 = b"p\x82\xe9T\xe4\xfdj\xdf\x8a%\xc6\xce\xfe!\x8f2\xecf\xd8\xa1\x97\x19\x7f\x1d\x05\xaag\xa6\\\xafQ\x11" # noqa: E501


logging.basicConfig(stream=sys.stdout, level=logging.INFO, format="%(message)s")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of this you can just use pytest tests/test_things.py --log-cli-level=INFO to get logging messages to show up in your terminal. This approach will unconditionally dump them to stdout which probably isn't globally desired.

Copy link
Member

@pipermerriam pipermerriam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not required for this PR but this new package management API almost definitely deserves multiple guides in the documentation.

Copy link
Collaborator

@carver carver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reminder to remove WIP from the title to signal that a merge is pending.

setup.py Outdated
"hexbytes>=0.1.0,<1.0.0",
"lru-dict>=1.1.6,<2.0.0",
"eth-hash[pycryptodome]>=0.2.0,<1.0.0",
"pytest-ethereum>=0.1.3a6,<1",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this should be moved to the tester extra, instead of as a core dependency.

Copy link
Contributor Author

@njgheorghita njgheorghita Jan 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, maybe I'm missing something, but we use pytest-ethereum's Deployer in the web3.pm module. But, I would say that this use case of using the Deployer is not that critical at all, since it's a relatively straightforward deployment. So, I can definitely pull it out, in which case pytest-ethereum would only be needed in the tests and help minimize the core dependencies.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I just did a Ctrl-f in the github diff, and the diff on pm was hidden.

At least semantically, I find it pretty surprising to use anything called pytest-* in the main deployed package. If Deployer is to be used in production code like this, then maybe it could be moved into a web3 _utils module.

LinkableContract,
)
from pytest_ethereum import (
linker as l,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One-letter variable? Maybe don't rename the import at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me, it was convention leftover from py-ethpm's builder tool to avoid from ethpm.builder import * but cut down on wordiness, but in this case isn't as useful.

web3/pm.py Outdated
The ERCRegistry class is a base class for all registry implementations to inherit from. It
defines the methods specified in `ERC 1319 <https://github.com/ethereum/EIPs/issues/1319>`__.
All of these methods are prefixed with an underscore, since they are not intended to be
accessed directly, but rather through the methods on ``web3.pm``.
Copy link
Collaborator

@carver carver Jan 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One important reason that we usually have for methods that are "not intended to be accessed directly" is that the API might change without a major version bump. Would be nice to add a note about whether these method signatures are subject to change. That's not super relevant during alpha, but we might as well document for stable now.

@njgheorghita njgheorghita changed the title WIP - Stabilize PM module Stabilize PM module Jan 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants