You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The pycardano library (the primitives definitions) is used by third party tools and respectively the high level tooling could benefit from using third party libraries (like ogmios). This may lead to cyclic dependencies
Describe the solution you'd like
Seperate the pycardano package into several packages
pycardano_primitives: All the building blocks defined by pycardano, transactions, Assets, PlutusData etc
pycardano_chain_contexts: The chain contexts shipped with pycardano, potentially even split further (ideally we want the abstract base class independently to allow third parties to implement it
pycardano_cips: The implementations of CIP proposals in pycardano
This can actually be performed transparently to users of the library by keeping pycardano as a single library that imports from all of the above (and potentially more)
Describe alternatives you've considered
The exact structure can be discussed.
Additional context
This allows the ogmios package to import the primitives from pycardano and transform Ogmios JSON serialized transactions into pycardano primitive Transactions. Meanwhile it can also implement the Ogmios 6 chain context that can be imported by pycardano.
Another example is uplc/opshin which can import pycardano primitives and implement a MockChainContext which does tx evaluation based on simulation of the Plutus VM.
The text was updated successfully, but these errors were encountered:
Thank you for bringing this up! I like this idea a lot. It will remove lots of dependency madness across many packages. Regarding package naming, I think we can come up with shorter names, something like:
Is your feature request related to a problem? Please describe.
The pycardano library (the primitives definitions) is used by third party tools and respectively the high level tooling could benefit from using third party libraries (like ogmios). This may lead to cyclic dependencies
Describe the solution you'd like
Seperate the pycardano package into several packages
pycardano_primitives
: All the building blocks defined by pycardano, transactions, Assets, PlutusData etcpycardano_chain_contexts
: The chain contexts shipped with pycardano, potentially even split further (ideally we want the abstract base class independently to allow third parties to implement itpycardano_cips
: The implementations of CIP proposals in pycardanoThis can actually be performed transparently to users of the library by keeping
pycardano
as a single library that imports from all of the above (and potentially more)Describe alternatives you've considered
The exact structure can be discussed.
Additional context
This allows the
ogmios
package to import the primitives from pycardano and transform Ogmios JSON serialized transactions into pycardano primitive Transactions. Meanwhile it can also implement the Ogmios 6 chain context that can be imported by pycardano.Another example is uplc/opshin which can import pycardano primitives and implement a MockChainContext which does tx evaluation based on simulation of the Plutus VM.
The text was updated successfully, but these errors were encountered: