Monorepo #254

vforvalerio87 · 2019-05-20T10:08:53Z

Set up monorepo:

this monorepo is organized as a PEP 420 compliant namespace
(https://www.python.org/dev/peps/pep-0420/).

The sdk package has been restructured to conform to the PEP 420
namespace package specification and it's under the "snet" namespace.

The cli package is both a regular package and a namespace package.

setup.py for the monorepo itself installs the dependencies for all
packages in the repository.

Each package and the overarching monorepo also have "requirements.txt"
files for local installations and CI enviroments: by installing via
"requirements.txt", the dependencies listed in "setup.py" are only
pulled and installed from PyPI if a local version is not already
available. This allows to get dependencies within the monorepo to be
installed from the local filesystem.

The whole package is called "snet" and gives the name to the namespace.
The subpackages are "snet.sdk", "snet.snet_cli" and snet_cli (since the
CLI package is both within the namespace and a regular package).
Going forward, all of the code in the "snet_cli" package can be migrated
to the namespace package: both were kept momentarily for compatibility.

In this scenario, everything inside the "snet.sdk" package has
visibility on the contents of the "snet.snet_cli" package and
vice-versa.
Everything inside the "snet_cli" regular package has visibility on the
contents of the "snet.snet_cli" package due to the regular Python import
mechanics, but it has no visibility on the contents of the "snet.sdk"
package (and vice-versa).
So, the shared code between the SDK and the CLI goes under the
"snet.snet_cli" package which is at "packages/snet_cli/snet/snet_cli".

Code and assets deduplication:

thanks to the new structure, everything under "resources" has been moved
to the "snet.snet_cli" package and is now shared between the SDK and
CLI. Specifically, this includes the json artifacts from the compilation
and deployment of the smart contracts, the raw ".proto" files to
interact with the daemon and the compiled python client libraries.

Changes:

since the CLI is both a namespace package and a regular package, changes
to the code have been kept to a minimum.
The only change of note is that state service does not compile its own
".proto" files at runtime inside the user's home directory anymore but
they are imported from the "resources" directory under the
"snet.snet_cli" namespace package, where they are compiled during setup.

astroseger · 2019-05-20T10:34:01Z

Could you add CI for your SDK (in functional tests). You can take it from: New sdk witch comply to new sdk-API (temporaly solution) #246
I would propose to remove compiled proto files from github ( snet_sdk/resources/proto).

astroseger · 2019-05-20T10:45:00Z

Could you give the simple example of usage of your SDK (similar to the example in the description of New sdk witch comply to new sdk-API (temporaly solution) #246)?

vforvalerio87 · 2019-05-20T23:44:40Z

Could you give the simple example of usage of your SDK (similar to the example in the description of New sdk witch comply to new sdk-API (temporaly solution) #246)?

https://github.com/singnet/snet-code-examples/pull/3/files

Matches the JS SDK example

astroseger · 2019-05-21T10:58:39Z

I would propose to not make separate directory for snet_cli and basically do not touch old directory structure for now and just add sdk directory. I afraid this move would make more harm then good (for example CI is brorken because of this now... )

astroseger · 2019-05-21T15:50:36Z

@vforvalerio87 Could you make your PR green before we review it?
I suggest doing: #254 (comment)

If you add some tests for SDK itself then it would be even greater...

raamb · 2019-05-22T05:07:18Z

I would propose to not make separate directory for snet_cli and basically do not touch old directory structure for now and just add sdk directory. I afraid this move would make more harm then good (for example CI is brorken because of this now... )

I suggest that we fix the CI for the folder structure ASAP. Infact I would propose that we merge in the new folder structure first to ensure that the client functionality is all fine. We can continue to work on the SDK in parallel. @vforvalerio87 lets get the CI for snet-cli fixed right away

astroseger · 2019-05-22T09:52:13Z

@raamb I do insist that we shoudn't touch directory structure of snet-cli. We could add sdk as separate folder, or, at first directly in snet-cli folder....
I do not see the reason to move files around... CI is broken because of it, and it is only the beginning of problems this movement will cause.

vforvalerio87 · 2019-05-23T12:09:50Z

So, CircleCI config and scripts have been adapted to work in the monorepo scenario, build tests pass.

I tried building and using both the CLI and SDK locally and they worked correctly, feel free to try the same.

I changed the name of the "stub" object to "service" as we discussed.

astroseger · 2019-05-23T12:32:09Z

@vforvalerio87
Please remove snet_sdk/snet_sdk/state_service_pb2.py and snet_sdk/snet_sdk/state_service_pb2_grpc.py from repo (you can compile them in setup.py as we do in snet-cli)

will you add tests for SDK in this PR (again feel free to reuse test infrastructure from #246)?

vforvalerio87 · 2019-05-23T13:53:34Z

@vforvalerio87
Please remove snet_sdk/snet_sdk/state_service_pb2.py and snet_sdk/snet_sdk/state_service_pb2_grpc.py from repo (you can compile them in setup.py as we do in snet-cli)

will you add tests for SDK in this PR (again feel free to reuse test infrastructure from #246)?

sure, I'll get to it as soon as I'm finished with updating the README

README.md

snet_sdk/scripts/blockchain

raamb · 2019-05-24T03:35:48Z

snet_sdk/snet_sdk/__init__.py

+from snet_sdk.account import Account
+from snet_sdk.mpe_contract import MPEContract
+from snet_sdk.payment_channel_management_strategies.default import PaymentChannelManagementStrategy
+


Lets use a similar approach to version as we did for the snet-cli i.e. use a version.py file which is changed via CD script. Makes it easier to control versioning in the code and Pypi. Can be taken up as its own PR

Sure, I had it like that because it used to be in init when I worked on the first iteration of the SDK... didn't notice it had changed places since then. I'll move it

arturgontijo

Some of the suggestions were already pointed by others:

Re-use blockchain/
Re-use scripts/
test/ should go to the main project folder
Maybe use just one .gitignore?
setup.py:
- python_requires='>=3.6',
- url='https://github.com/singnet/snet-sdk-python', -> "monorepo"
MANIFEST.in:
- snet_sdk/resources/proto/* doesn't exist.
- Re-use resources/ ?
VERSION (sdk gets it in a different way from cli).
Unused imports (init.py):
- import operator
- from functools import reduce
- import sys
- import os
- import importlib
- import base64
- from pathlib import PurePath, Path
- import hashlib
- import collections
- from eth_account.messages import defunct_hash_message
- import snet_sdk.generic_client_interceptor as generic_client_interceptor
init.py#L58
create_service_client(..., options={}) -> Mutable argument.
create_service_client(..., options=None)
if options is None:
options = dict()
Suggestion (mpe_contract.py):
Maybe EVENT_ABI could be set like it is in snet_cli/mpe_channel_command.py#L423
Unused arguments (service_client.py#L81):
request_streaming and response_streaming
Remove compiled state_service.proto codes.

astroseger · 2019-05-27T15:27:23Z

@vforvalerio87

snet_sdk require grpcio-tools==1.17.1 and web3==4.2.1
snet_cli require web3==4.8.3 and grpcio-tools==1.19.0
So I was not able to install snet_sdk. After I had changed grpcio-tools and web3 requirement in snet_sdk/setup.py I still was not able to run your example: https://github.com/singnet/snet-code-examples/pull/3/files

It gives the following error:

Traceback (most recent call last):
  File "test.py", line 1, in <module>
    from snet_sdk import SnetSDK
  File "/home/seger/work/workspace/signet/gits/snet-cli/snet_sdk/snet_sdk/__init__.py", line 18, in <module>
    from web3.utils.datastructures import AttributeDict, MutableAttributeDict
ModuleNotFoundError: No module named 'web3.utils.datastructures'

I suppose it is not working with web3==4.8.3 which snet-cli requires.

So I was not able to run your example...

astroseger · 2019-05-27T15:55:20Z

@vforvalerio87
I have two additional comments and one request:

Could you provide two examples (better add them directly in functional tests):

Example with running "BasicStrategy" which do not extend or add funds to the channel
Example with running AutoFundingFundingStrategy with explicitly passing "amount_cogs" + "expiration" (or how you call them :) ).

Comment 1:
We should use the same strategy for funding channels across all components. We've already discussed it with @raamb (about dApp) and we've agreed with the following strategy:

We take appropriate channel with smallest channelId.
It means that if there are several channels which were found we simply get channel with smaller channelId.
We do not search for "funded" channel and we do not propose user to open new channel. We always reuse old channel. We are doing it in snet-cli and dApp, so please do the same in SDK.

You are not doing it in _get_funded_channel (you should simply take channel with smallest channelId and return it even if it is not founded)

Comment 2:
You use self.metadata.pricing["price_in_cogs"] directly which you shouldn't do. We will add new pricing models soon, so we might not have price_in_cogs. I would propose to have a special function get_price_for_next_call

chetankothari · 2019-05-28T11:59:31Z

snet_sdk/snet_sdk/__init__.py

+            group = next(filter(lambda group: group["group_name"] == group_name, service_metadata.groups))
+        except StopIteration:
+            raise ValueError("Group[name: {}] not found for orgId: {} and serviceId: {}".format(group_name, org_id, service_id))
+        service_client = ServiceClient(self, service_metadata, group, service_stub, payment_channel_management_strategy(self), options)


I think we should accept an instance rather than instantiate it here. That way we don't have to worry about freezing the constructor api for the PaymentChannelManagmentStrategy.

vforvalerio87 · 2019-05-31T03:24:08Z

Hey, I was working on the CLI command to compile the client libraries for JS. I reviewed all the comments:

I fixed the unused imports, am about to push a commit for that. Also fixed manifest, version.
CLI setup.py now downloads and compiles the required node_module for generating JS client libraries. This is done in setup.py instead of the "blockchain install" script as the node_module (grpc-tools) has to be compiled for the CLI user's architecture so it cannot be built and packaged with the CLI distributable
About the modules used in the CLI and SDK, I used two different virtual envs in my tests. I'll look to update the modules used in the SDK package too
About the pricing and channel selection strategy: I straight up copied what's being done in the JS SDK for consistency so if we want to change how it works, we should do the same in JS. Agree we should have an abstracted "get_price_for_next_call".

raamb · 2019-06-04T05:57:33Z

I fixed the unused imports, am about to push a commit for that. Also fixed manifest, version.

@vforvalerio87 have the commits been pushed?

Reorganized sdk and cli to be two different packages in the same repository Moved sdk to cli repo Rewrote SDK to match JS SDK implementation CircleCI fix

…el with interceptor in service_client instance

optional parameter Added call allowance to payment channel strategy as an optional parameter Split .gitignore to have a top level one and separate ones for each package Same for LICENSE Updated CLI README, added top-level README (sdk-specific is still in progress)

…manifest

this monorepo is organized as a PEP 420 compliant namespace (https://www.python.org/dev/peps/pep-0420/). The sdk package has been restructured to conform to the PEP 420 namespace package specification and it's under the "snet" namespace. The cli package is both a regular package and a namespace package. setup.py for the monorepo itself installs the dependencies for all packages in the repository. Each package and the overarching monorepo also have "requirements.txt" files for local installations and CI enviroments: by installing via "requirements.txt", the dependencies listed in "setup.py" are only pulled and installed from PyPI if a local version is not already available. This allows to get dependencies within the monorepo to be installed from the local filesystem. The whole package is called "snet" and gives the name to the namespace. The subpackages are "snet.sdk", "snet.snet_cli" and snet_cli (since the CLI package is both within the namespace and a regular package). Going forward, all of the code in the "snet_cli" package can be migrated to the namespace package: both were kept momentarily for compatibility. In this scenario, everything inside the "snet.sdk" package has visibility on the contents of the "snet.snet_cli" package and vice-versa. Everything inside the "snet_cli" regular package has visibility on the contents of the "snet.snet_cli" package due to the regular Python import mechanics, but it has no visibility on the contents of the "snet.sdk" package (and vice-versa). So, the shared code between the SDK and the CLI goes under the "snet.snet_cli" package which is at "packages/snet_cli/snet/snet_cli". Code and assets deduplication: thanks to the new structure, everything under "resources" has been moved to the "snet.snet_cli" package and is now shared between the SDK and CLI. Specifically, this includes the json artifacts from the compilation and deployment of the smart contracts, the raw ".proto" files to interact with the daemon and the compiled python client libraries. Changes: since the CLI is both a namespace package and a regular package, changes to the code have been kept to a minimum. The only change of note is that state service does not compile its own ".proto" files at runtime inside the user's home directory anymore but they are imported from the "resources" directory under the "snet.snet_cli" namespace package, where they are compiled during setup.

vforvalerio87 · 2019-06-08T01:41:06Z

Set up monorepo:

this monorepo is organized as a PEP 420 compliant namespace
(https://www.python.org/dev/peps/pep-0420/).

The sdk package has been restructured to conform to the PEP 420
namespace package specification and it's under the "snet" namespace.

The cli package is both a regular package and a namespace package.

setup.py for the monorepo itself installs the dependencies for all
packages in the repository.

Each package and the overarching monorepo also have "requirements.txt"
files for local installations and CI enviroments: by installing via
"requirements.txt", the dependencies listed in "setup.py" are only
pulled and installed from PyPI if a local version is not already
available. This allows to get dependencies within the monorepo to be
installed from the local filesystem.

The whole package is called "snet" and gives the name to the namespace.
The subpackages are "snet.sdk", "snet.snet_cli" and snet_cli (since the
CLI package is both within the namespace and a regular package).
Going forward, all of the code in the "snet_cli" package can be migrated
to the namespace package: both were kept momentarily for compatibility.

In this scenario, everything inside the "snet.sdk" package has
visibility on the contents of the "snet.snet_cli" package and
vice-versa.
Everything inside the "snet_cli" regular package has visibility on the
contents of the "snet.snet_cli" package due to the regular Python import
mechanics, but it has no visibility on the contents of the "snet.sdk"
package (and vice-versa).
So, the shared code between the SDK and the CLI goes under the
"snet.snet_cli" package which is at "packages/snet_cli/snet/snet_cli".

Code and assets deduplication:

thanks to the new structure, everything under "resources" has been moved
to the "snet.snet_cli" package and is now shared between the SDK and
CLI. Specifically, this includes the json artifacts from the compilation
and deployment of the smart contracts, the raw ".proto" files to
interact with the daemon and the compiled python client libraries.

Changes:

since the CLI is both a namespace package and a regular package, changes
to the code have been kept to a minimum.
The only change of note is that state service does not compile its own
".proto" files at runtime inside the user's home directory anymore but
they are imported from the "resources" directory under the
"snet.snet_cli" namespace package, where they are compiled during setup.

vforvalerio87 · 2019-06-08T02:21:31Z

Some of the suggestions were already pointed by others:

Re-use blockchain/

Re-use scripts/

Done

test/ should go to the main project folder

I'd probably have each package have its own tests but we can discuss this

Maybe use just one .gitignore?

This is easier if stuff gets moved around since everything is relative to the package itself. More compartmentalized

setup.py:

python_requires='>=3.6',

Done

url='https://github.com/singnet/snet-sdk-python', -> "monorepo"

MANIFEST.in:

snet_sdk/resources/proto/* doesn't exist.

Re-use resources/ ?

This is dead now. All resources are in the cli package

VERSION (sdk gets it in a different way from cli).

Done

Unused imports (init.py):

import operator

from functools import reduce

import sys

import os

import importlib

import base64

from pathlib import PurePath, Path

import hashlib

import collections

from eth_account.messages import defunct_hash_message

import snet_sdk.generic_client_interceptor as generic_client_interceptor

Fixed

init.py#L58
create_service_client(..., options={}) -> Mutable argument.
create_service_client(..., options=None)
if options is None:
options = dict()

Fixed

Suggestion (mpe_contract.py):
Maybe EVENT_ABI could be set like it is in snet_cli/mpe_channel_command.py#L423

Done

Unused arguments (service_client.py#L81):
request_streaming and response_streaming

_intercept_call is passed as an argument to generic_client_interceptor.create, which returns a _GenericClientInterceptor instantiated with _intercept_call as a parameter, its own self._fn equals _intercept_call, self._fn is always called with 4 parameters (+ self), so if you remove those two parameters from _intercept_call, the interceptor class is going to error out.

Remove compiled state_service.proto codes.

Done!

getting abi for OpenChannel event from the contract object using web3 function passing instance of payment channel management strategy to service client

vforvalerio87 · 2019-06-08T11:17:36Z

Obviously a lot more code can be shared and reused now, but I wanted to get the new repository structure understood and merged in first to serve as a basis for refactoring, especially to reuse the CLI code for dynamic compilation. Additional refactoring can come in later PRs

… package, moved version identifier

astroseger

Please add at least a simple test for SDK, we have dummy daemon and all necessary infrastructure in snet-cli for it...
The problem with this approach (in comparison to New sdk witch comply to new sdk-API (temporaly solution) #246 !!! ) that a lot of staff now is implemented differently in snet-cli and sdk (not talking about much bigger development time):

gas_price_strategies
functions to get channel state from the service
functions to get channel for given service
dynamic protobuf compilations (which present in snet-cli but absent in SDK)
etc..
And it will cause problems. For example Full stateless logic #241 will fix _get_channel_state_statelessly for snet-cli but not for your sdk...
I understand that the goal is to eliminate such duplication, but it is not clear how long it will take to do it...

astroseger · 2019-06-13T12:58:20Z

packages/sdk/snet/sdk/__init__.py

+        eth_rpc_endpoint = self._config.get("eth_rpc_endpoint", "https://mainnet.infura.io")
+        provider = web3.HTTPProvider(eth_rpc_endpoint)
+        self.web3 = web3.Web3(provider)
+        self.web3.eth.setGasPriceStrategy(rpc_gas_price_strategy)


Have you tested this rpc_gas_price_strategy? How high gas price returned by this method in comparison to time based gas price strategies (fast, medium, slow). The problem is that after this PR snet-cli and sdk will use different gas price strategies...

Haven't tested it compared to other strategies, I'll change it to default to medium or selectable by config parameter

astroseger · 2019-06-13T13:00:30Z

packages/sdk/snet/sdk/__init__.py

+        if options is None:
+            options = dict()
+
+        service_metadata = self.service_metadata(org_id, service_id)


I would rename function to get_service_metadata, otherwise there is a name "clash".

In snet-cli we have special class for metadata (mpe_service_metadata.py). I would propose to use it here. It already has functions which we need here.

astroseger · 2019-06-13T13:05:00Z

packages/sdk/snet/sdk/__init__.py

+
+        service_metadata = self.service_metadata(org_id, service_id)
+        try:
+            group = next(filter(lambda group: group["group_name"] == group_name, service_metadata.groups))


MPEServiceMetadata already has function get_group. We could use it, instead of re-implementing it.

astroseger · 2019-06-13T13:08:22Z

packages/sdk/snet/sdk/__init__.py

+
+    def service_metadata(self, org_id, service_id):
+        (found, registration_id, metadata_uri, tags) = self.registry_contract.functions.getServiceRegistrationById(bytes(org_id, "utf-8"), bytes(service_id, "utf-8")).call()
+        metadata = AttributeDict(json.loads(self.ipfs_client.cat(metadata_uri.rstrip(b"\0").decode('ascii')[7:])))


We should use snet_cli.utils_ips.get_from_ipfs_and_checkhash function here (we should checksum).
Please see MPEServiceCommand._get_service_metadata_from_registry function.

astroseger · 2019-06-13T13:10:46Z

packages/sdk/snet/sdk/account.py

+    def _send_signed_transaction(self, contract_fn, *args):
+        transaction = contract_fn(*args).buildTransaction({
+            "chainId": int(self.web3.version.network),
+            "gas": DEFAULT_GAS, 


I'm not sure that we should specify "gas" parameter here. In snet-cli we don't do it and it is estimated automatically (see contract.py in snet-cli). By the way we could reuse contract.py from snet-cli.

I tried removing it... it works locally but randomly fails for me when working with Kovan or Ropsten through Infura (ValueError: {'code': -32000, 'message': 'gas required exceeds allowance or always failing transaction'}). Works every time if a high enough gas parameter is manually specified. The eth_estimateGas RPC seems to be unreliable on Infura.

I get the same error with the "client call" command of the CLI by the way.

astroseger · 2019-06-13T13:22:23Z

packages/snet_cli/snet_cli/commands.py


+from snet.snet_cli.utils import DefaultAttributeObject, get_web3, serializable, type_converter, get_contract_def, get_cli_version, bytes32_to_str


Could you explain again new directory structure. I do not understand some details.
Why utils.py are moved packages/snet_cli/snet/snet_cli and the rest of snet-cli is in packages/snet_cli/snet_cli. Why? Is utils.py still a part of snet-cli package? or is it in a separate package now?

So, now we have:
snet_cli (the regular, old package)
Then there is snet which is a PEP 420 "namespace package" which has two subpackages:
snet.snet_cli
snet.sdk

PEP 420 namespace packages have the following directory structure:
<package_a> -> <namespace_package> -> <package_a>

If you have another package in your file system with a directory structure like <package_a> -> <namespace_package> -> <package_a>, then package_a and package_b can share code between them. It can be imported as namespace_package.package_a and namespace_package.package_b from any of the two.

So, in the CLI package everything that is under snet_cli/snet_cli is not shared; everything that is under snet_cli/snet/snet_cli can be used in the sdk package by importing from snet.snet_cli.

The sdk only needs what is under snet_cli/snet/snet_cli to work (it will be published as a separate package), not the whole snet_cli package.

astroseger · 2019-06-13T13:57:22Z

packages/sdk/snet/sdk/payment_channel_management_strategies/default.py

+        self.block_offset = block_offset
+        self.call_allowance = call_allowance
+
+    def select_channel(self, service_client):


To be consistent with snet-cli and dApp one should get channel with smallest channel id. See also singnet/snet-sdk-js#4 .

astroseger · 2019-06-13T14:08:00Z

packages/sdk/snet/sdk/mpe_contract.py

+        self.deployment_block = get_contract_deployment_block(self.web3, "MultiPartyEscrow.json")
+
+
+    def get_past_open_channels(self, account, service, starting_block_number=0, to_block_number=None):


Why this function is so complicated? Why it is required to read logs in batches (while loop)??? Please take a look at MPEChannelCommand._get_all_filtered_channels in mpe_channel_command.py. It works perfectly without while loop. We should simply combine _get_all_channels_filter_sender_recipient_group and _get_all_filtered_channels

Getting all the logs from the deployment block to the current block is randomly giving me errors from Infura on both Ropsten and Kovan.

Also, _get_all_channels_filter_sender_recipient_group uses _get_all_filtered_channels which requires functions that rely on the CLI configuration and identity which work quite differently from the SDK.

I would open an issue for this, look into it and change it in a subsequent PR, after I'm finished with the dynamic compilation.

astroseger · 2019-06-13T14:16:25Z

packages/sdk/snet/sdk/service_client.py

+    def _get_grpc_channel(self):
+        endpoint = self.options.get("endpoint", None)
+        if endpoint is None:
+            endpoint = next(filter(lambda endpoint: endpoint["group_name"] == self.group["group_name"], self.metadata["endpoints"]))["endpoint"]


I would propose to use get_endpoints_for_group from MPEServiceMetadata here (and use MPEServiceMetadata class in general)

astroseger · 2019-06-13T14:25:00Z

packages/sdk/snet/sdk/account.py

+        return self.web3.toHex(self.web3.eth.sendRawTransaction(signed_txn.rawTransaction))
+
+
+    def send_transaction(self, contract_fn, *args):


Why function for sending transaction is in Account class? In Account class two entities are mixed:

class for ETH/MPE account (analog of MPEAccountCommand from snet-cli)

class which sends on-chain transactions (analog of ContractCommand from snet-cli)

I would propose to reuse contract.py from snet-cli and probably write "better" version of ContractCommand, but not mixing two different entities here...

contract.py and ContractCommand are different. contract.py does not do much.

Right now in the CLI sending transactions is all done by the Identity class as the process is different for all identity types, while only calls and building transactions is done by contract.py as that's the same for all identity types.

I can reuse contract.py for calls and building transactions in the SDK too, I can move the logic for sending transactions in another class (an analog to the CLI identity class but for the SDK), but I would not reuse the identity class or the ContractCommand class in the SDK as they are in the CLI as they rely heavily on CLI-specific configuration and identity

restyled-io · 2019-06-25T02:38:12Z

Hey there-

I'm a bot, here to let you know that some code in this PR might not
match the team's automated styling. I ran the team's auto-reformatting tools on
the files changed in this PR and found some differences. Those differences can
be seen in #260.

Please see that Pull Request's description for more details.

…d package Refactored SDK package to use shared code

raamb · 2019-06-26T16:49:41Z

@arturgontijo @astroseger request your feedback on this. Thanks in advance

vforvalerio87 force-pushed the monorepo branch from 1462707 to ebcf422 Compare May 20, 2019 23:39

vforvalerio87 force-pushed the monorepo branch from ebcf422 to d9026da Compare May 21, 2019 12:03

vforvalerio87 force-pushed the monorepo branch from d9026da to 33ab122 Compare May 21, 2019 16:23

vforvalerio87 force-pushed the monorepo branch from 33ab122 to 92335ac Compare May 23, 2019 10:23

vforvalerio87 force-pushed the monorepo branch from c25c09a to 2ff6d2d Compare May 23, 2019 13:18

vforvalerio87 force-pushed the monorepo branch from 8251827 to a295aa7 Compare May 23, 2019 14:34

raamb reviewed May 24, 2019

View reviewed changes

README.md Show resolved Hide resolved

raamb reviewed May 24, 2019

View reviewed changes

snet_sdk/scripts/blockchain Outdated Show resolved Hide resolved

raamb reviewed May 24, 2019

View reviewed changes

raamb requested review from astroseger and arturgontijo May 24, 2019 10:07

arturgontijo suggested changes May 24, 2019

View reviewed changes

chetankothari reviewed May 28, 2019

View reviewed changes

astroseger mentioned this pull request May 31, 2019

snet-sdk-js should select the channel with smallest channel_id in case of several channels. singnet/snet-sdk-js#4

Open

vforvalerio87 force-pushed the monorepo branch 2 times, most recently from 5c79127 to 3470ab7 Compare June 5, 2019 09:10

vforvalerio87 added 8 commits June 8, 2019 03:34

Monorepo first commit

73ba53e

Reorganized sdk and cli to be two different packages in the same repository Moved sdk to cli repo Rewrote SDK to match JS SDK implementation CircleCI fix

fix gitignore

45581ad

fix to setup.py to include contract jsons

8c018f9

renamed stub object to service in service_client, exposing grpc chann…

46bef82

…el with interceptor in service_client instance

updated readme for SDK, fixed a link in the CLI readme

96633a4

removed unused imports, moved version, removed unused resources from …

052d9b3

…manifest

vforvalerio87 force-pushed the monorepo branch from 8c4efed to 63e2a0a Compare June 8, 2019 01:38

Fixed mutable argument in service client constructor,

7113b17

getting abi for OpenChannel event from the contract object using web3 function passing instance of payment channel management strategy to service client

fixed basic setup for CLI, added setup and requirements for namespace…

22ed5db

… package, moved version identifier

astroseger reviewed Jun 13, 2019

View reviewed changes

restyled-io bot mentioned this pull request Jun 25, 2019

Restyle Monorepo #260

Closed

Moved mpe_channel_command, mpe_service_metadata and contract to share…

ca6044b

…d package Refactored SDK package to use shared code

vforvalerio87 force-pushed the monorepo branch from ac4fa63 to ca6044b Compare June 25, 2019 03:04

arturgontijo approved these changes Jun 26, 2019

View reviewed changes

This was referenced Jun 27, 2019

Use get_all_filtered_channels across cli and sdk #262

Open

Test cases for the SDK #263

Open

raamb merged commit 5474f0f into singnet:master Jun 28, 2019

vforvalerio87 deleted the monorepo branch July 1, 2019 07:39


		from snet.snet_cli.utils import DefaultAttributeObject, get_web3, serializable, type_converter, get_contract_def, get_cli_version, bytes32_to_str

		self.deployment_block = get_contract_deployment_block(self.web3, "MultiPartyEscrow.json")


		def get_past_open_channels(self, account, service, starting_block_number=0, to_block_number=None):

		return self.web3.toHex(self.web3.eth.sendRawTransaction(signed_txn.rawTransaction))


		def send_transaction(self, contract_fn, *args):

Monorepo #254

Monorepo #254

Conversation

vforvalerio87 commented May 20, 2019 • edited Loading

astroseger commented May 20, 2019

astroseger commented May 20, 2019

vforvalerio87 commented May 20, 2019

astroseger commented May 21, 2019

astroseger commented May 21, 2019

raamb commented May 22, 2019

astroseger commented May 22, 2019 • edited Loading

vforvalerio87 commented May 23, 2019

astroseger commented May 23, 2019 • edited Loading

vforvalerio87 commented May 23, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arturgontijo left a comment

Choose a reason for hiding this comment

astroseger commented May 27, 2019 • edited Loading

astroseger commented May 27, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vforvalerio87 commented May 31, 2019

raamb commented Jun 4, 2019

vforvalerio87 commented Jun 8, 2019

vforvalerio87 commented Jun 8, 2019

vforvalerio87 commented Jun 8, 2019

astroseger left a comment • edited Loading

Choose a reason for hiding this comment

astroseger Jun 13, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

astroseger Jun 13, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

astroseger Jun 13, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

astroseger Jun 13, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

astroseger Jun 13, 2019 • edited Loading

Choose a reason for hiding this comment

vforvalerio87 Jun 25, 2019 • edited Loading

Choose a reason for hiding this comment

astroseger Jun 13, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

astroseger Jun 13, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

astroseger Jun 13, 2019 • edited Loading

Choose a reason for hiding this comment

vforvalerio87 Jun 25, 2019 • edited Loading

Choose a reason for hiding this comment

astroseger Jun 13, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

astroseger Jun 13, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

restyled-io bot commented Jun 25, 2019

raamb commented Jun 26, 2019

vforvalerio87 commented May 20, 2019 •

edited

Loading

astroseger commented May 22, 2019 •

edited

Loading

astroseger commented May 23, 2019 •

edited

Loading

astroseger commented May 27, 2019 •

edited

Loading

astroseger commented May 27, 2019 •

edited

Loading

astroseger left a comment •

edited

Loading

astroseger Jun 13, 2019 •

edited

Loading

astroseger Jun 13, 2019 •

edited

Loading

astroseger Jun 13, 2019 •

edited

Loading

astroseger Jun 13, 2019 •

edited

Loading

astroseger Jun 13, 2019 •

edited

Loading

vforvalerio87 Jun 25, 2019 •

edited

Loading

astroseger Jun 13, 2019 •

edited

Loading

astroseger Jun 13, 2019 •

edited

Loading

astroseger Jun 13, 2019 •

edited

Loading

vforvalerio87 Jun 25, 2019 •

edited

Loading

astroseger Jun 13, 2019 •

edited

Loading

astroseger Jun 13, 2019 •

edited

Loading