Provider and Registrar refactory
- Dominant language
- No language data
- Stars
- 319
- Forks
- 110
- PR merge metrics
- No merged PRs in 30d
Description
### What was wrong?
Primary things that are being fixed here.
1. Dependency on the `Chain` class which is slated to be deprecated.
2. Registrar and Provider API should be independent.
3. Provider access to registrar should be done via provider backend API.
### How it should be fixed.
#### Step 1
Minimal code change to remove `chain` as dependency and switch to constructor taking `web3`, `registrar` and `provider_backends`.
#### Step 2
Refactor provider API to use *minimal* ERC190 package spec to store serialized packages.
- Introduce new API for setting package name in all places where storing deployments would happen.
- if a package name is not provided, create one using automated whole number versioning name generation. `ContractName-v1`.
- if package name is not provided raise `PendingDeprecation` warning indicating that it will be required *soon*
- store *all* deployments in a JSON document for the time being.
- figure out strategy for test runs to ensure we don't pollute the registrar JSON file.
#### Step 3
Decouple provider and registrar into independent backend APIs.
- `Registrar.record_package`
- `Registrar.lookup_package`
- `Provider.get_contract_address`
- `Provider.is_contract_available`
- `Provider.is_contract_available`
- `Provider.are_contract_dependencies_available`
- `Provider.get_contract_instance` (replaces and deprecates `Provider.get_contract`)
- `Provider.get_contract_factory`
- `Provider.get_base_contract_factory`
- Deprecate: `Provider.get_all_contract_data`
- Deprecate: `Provider.get_all_contract_names`
- Deprecate: `Provider.get_contract_data`
The term `contract_identifier` in these apis should use scheme similar to the one laid out in https://github.com/ethereum/populus/issues/373 for differentiating between which contract is being retrieved.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the Chain dependency and the Provider and Registrar APIs described in Steps 1–3. Review the contract identifier approach in issue #373, then map the listed API changes and deployment JSON requirements before defining tests for independent Provider and Registrar backends. Done means the deprecated Chain dependency is removed and the listed API and storage behavior are covered.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend-api-design, blockchain
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 20/100