-
Notifications
You must be signed in to change notification settings - Fork 720
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
Adapt packages to use Protocol type class #2498
Conversation
0d28c0e
to
068e593
Compare
Per @nc6 , we don't have to support GHC 8.6, and those are the only tests that are failing, so we can go ahead with this. |
e17fad5
to
2de0102
Compare
4c9f837
to
9b57f62
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the changes but I would get a sign off from @dcoutts
a9013ff
to
d59426d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Just in case there are conflicts, this should go in after PR #2547. There probably won't be, but just to be safe.
bors merge |
bors r- |
Canceled. |
Sorry I didn't see the comment at first. Thanks! |
2547: API refactoring to move scripts into the txbody r=Jimbo4350 a=dcoutts REMOVE: Merge #2498 after this PR has been merged This is the first step in a refactoring that we will need for Alonzo support. The refactoring will put the scripts within the tx body at the sites where they are used. For Shelley era scripts we can do it either way round, but for Alonzo it makes much more sense to place the script at the use sites. So to break the Alonzo changes into steps we do the refactoring for the existing Shelley-based eras first. The ideas here have been co-authored with Jordan Millar and most of the code changes here appeared first in his Alonzo branch. - [x] Update the API tests for these API changes - [x] Update the CLI for these API changes There are a couple breaking changes: - You must specify auxiliary scripts with `--auxiliary-script-file` instead of `--script-file` - Scripts witnessing txins, certificates, withdrawals and minting must be paired with the thing they are witnessing. E.g: ``` --certificate-file $certfile --certificate-script-file $scriptfile --tx-out $txout --minting-script-file $scriptfile --withdrawal $withdrawal --withdrawal-script-file $scriptfile --tx-in $txin --txin-script-file $scriptfile ``` - Scripts are no longer specified at the tx signing stage. They are specified at the txbody stage. Co-authored-by: Duncan Coutts <duncan@well-typed.com> Co-authored-by: Jordan Millar <jordan.millar@iohk.io>
The way ouroboros-network exposes Protocol information to clients such as cardano-api and cardano-node was changed from a Protocol GADT, which lived in ouroboros-network, to a type class that lives in this repo; similarly for ProtocolClient. These changes make the universe of Protocols that can be run more open than before. cardano-api, cardano-cli, cardano-node, and cardano-node-chairman are here modified to use this type class as much as possible. At some point they do have to close their assumptions on which modes are supported, but this is pushed up to the top-level as much as possible.
d59426d
to
7402029
Compare
bors r+ |
Build succeeded: |
This PR depends on IntersectMBO/ouroboros-network#2978
In that PR, the
Protocol
type that the cardano-node packages use is removed. This is so that ouroboros-network does not need to enumerate all the consensus modes it implements. The majority of changes in this PR are in reaction to that, creating a type class to replace it.We found that it would take a significant increase in code complexity to remove the explicit enumeration of supported consensus modes in two places:
For that purpose, we have written the GADT
BlockType
which provides the little bit of type discovery these places need.In addition, we have removed the
Enum
instance forAnyCardanoEra
. The motivation is that we anticipate the inclusion of experimental eras and consensus modes in the code base which cannot reasonably be said to be enumerable among the mainnet eras. This instance does not appear to be used anywhere. If it needs to be preserved then we will need an answer on how to handle eras we don't expect to be part of mainnet (at least when they are first implemented).