Closed approxit closed 1 year ago
yapapi.payload.vm
and other yapapi.payload
artifacts in golem-core:
AutodecoratingModel
exists? properties
and constrains
as a collection on the same level (instead of having two separated collections)? Package.from_image_hash
so it doesn't spin asyncio event loopPackage.resolve_url()
so it returns plain url instead of str decorated with prefix and sufixGftpProvider
to golem-core, limit it to only classes and functions necessary for golem-core (e.g. Destination
and Source
abstract classes)_YagnaDatetimeFormatter
to golem-corerest.Configuration
yapapi/config.py:ApiConfig
and add logic resposible for creating default ya_
urls.ya_
clients based on given ApiConfig
self._api_config.market()
calls with calls to new factory. e.g.:
self._ya_market_api = ApiFactory(self._api_config).create_market_api()
DEFAULT_DRIVER, DEFAULT_NETWORK, DEFAULT_SUBNET
to golem-coregolem_node.GolemNode.create_demand
so it doesn't use yapapi's DemandBuilder
nor props
__str__
method from NoPaymentAccountError
to NoMatchingAccount
is_intermittent_error
_is_gsb_endpoint_not_found_error
As golem-core reached its MVP, we should follow up its state with already existing yapapi. As its not currently known if we want to merge those projects, or keep them separate, we know that we need to get rid of
yapapi
dependency ingolem-core
.golem-core
should take role of the lowest python level library, so noyapapi
dependencies should exists.As list of dependencies is not yet known, we decided that we need first to check the
golem-core
codebase, and list all ofyapapi
dependencies.To do:
yapapi
modules/classes/flows that are used bygolem-core
for later replacement