ADR-0004 Common PAB API document #586
Conversation
…Added concrete decisions that we will make if the proposal is accepted.
ghost
self-requested a review
doc/adr/0004-common-pab-api.rst
Outdated
|
|
||
| The PAB Contract (defined in `plutus-apps`) is using the `freer-simple` effect system to define all the contract effects. This already allows us to separate the interface from the implementation, or to have multiple implementations for one interface. | ||
|
|
||
| Our proposal, is to further separate these two components: create a separate repository with these contract effects and types, but without any implementation or any unnecessary dependencies. By moving the contracts out of the plutus-apps monorepository, any tool could update to newer version to their discretion. Without many dependencies, many tools could utilize the contract API without having to depend on the whole plutus-apps monorepo. |
There was a problem hiding this comment.
I think having the contract effects and types in a separate package should be enough right? I don't see the need for a separate repository.
There was a problem hiding this comment.
The disadvantage of this is that cabal will have to clone the whole repo to use the package (haskell/cabal#7264).
There was a problem hiding this comment.
That's a downside that seems pretty minor to us not having a monorepo anymore.
There was a problem hiding this comment.
Another downside is that PAB will not be able to use a different version of the interface. Tools, that only use the interface would have to wait for the PAB implementation. And the reality is that the PAB implementation is lagging behind the hardfork, and we're unsure when we will be able to use Vasil features (this is the main reason for this proposal).
There was a problem hiding this comment.
Ideally, the interface would be updated well before a testnet hardfork, so library developers can start building on it.
There was a problem hiding this comment.
Right, we could do that with a separate branch, like we do now with the next-node branch, but that's a bit of a kludge.
There was a problem hiding this comment.
It'd also allow this specific "interface-only" package not depend on a great amount of packages that may also need to be updated for it to work. A separate repo will ensure the interface package is truly minimal, easy to depend on, and implement an interpreter for. Of course, it'll also make this interface-only repo much easier to maintain.
Kll/adr 0004 common pab api
Co-authored-by: koslambrou <[email protected]>
Co-authored-by: koslambrou <[email protected]>
Renamed ADR, marked as proposed, and added the Implications and Notes sections
…r-0004-common-pab-api
See the end result here: https://plutus-apps--586.org.readthedocs.build/en/586/adr/0004-common-pab-api.html
Pre-submit checklist: