informalsystems / apalache-chai Goto Github PK

Required so we can run the Shai server for integration tests.

As per informalsystems/modelator-py#65, apparently I'll need to pull the minimum python version back down to support integration with MBT code bases. This will require some amount of fiddling with code to drop the newer idioms.

The protobuf specs belong to Apalache, and that should be the source of truth. But we want to pull those in for code generation of the gRPC interfaces here. We'll need

• A way to pin a version of Chai to a version of Apalache to obtain the expected protobuf files
  • #4
  • #5
• Generation of the gRPC boilerplate from the Apalache protobuf specs https://github.com/informalsystems/apalache/tree/unstable/shai/src/main/protobuf

Work on the cmd_executor ended up exposing mechanisms for transparent configuration of Apalache execution. However, the client code in trans_exporer.py was implemented prior to these features. The latter should be re-worked to take advantage of the developments introduced for the former.

Enabling projects or use-cases to use the library without forcing them to work in async. Tho the MBT team is also planning to port their code base to use async, providing a blocking interface should be generally useful, and it could expedite their adoption.

If the work takes me more than 1 day, I'll de prioritize it for other work.

Integration tests fail in CI with

error: could not set permissions on '/nix/var/nix/profiles/per-user' to 755: Operation not permitted

Probably caused by cachix/install-nix-action#148

For a full log, see this job

The basic need is for a way of sharing the proto schemata between Apalache, Chai, and any subsequent libraries that may wish to use the them.

After reviewing several discussions around ways to share protobuf schemata between different cod bases, it looks like breaking the proto files into their own repo and using git submodules are likely the most lightweight and platform and stack agnostic approach.

Discussions I reviewed include the following:

• https://stackoverflow.com/questions/38862101/how-do-i-share-protocol-buffer-proto-files-between-multiple-repositories
• https://andrealeopardi.com/posts/sharing-protobuf-schemas-across-services/
• https://www.reddit.com/r/grpc/comments/fywj7y/best_practice_to_share_protobuf_between_git/

This will important since the aim of this library is to be used by people who haven't been involved with it's development.

To help illustrate use, we will create a short tutorial with example code that
be run in integration tests.

The example should cover:

• How to start the server.
• How to instantiate a client.
• How to obtain a connection to the server.
• How to make RPC calls.
• How to process data received from the RPC calls.

In MBT's most immediate use case, they're likely to want to to be able to call the client async, so that they can do other stuff while the server is processing expensive queries. Since it's quite easy to make async calls blocking, but takes more work to go the other way, we should start using asyncio in the client, and later write a blocking wrapper if needed.

We seem to be hitting informalsystems/apalache#2177 on our MacOS runner: https://github.com/informalsystems/apalache-chai/actions/runs/3201757378/jobs/5230047315#step:12:19

Will need to figure out how to configure a newer java version, tho I'm surprised we're hitting this since we should be using the java dependency via the nix environment..

With the exception of the initial rpc call, connect (which is really more an extension of the grpc protocol for us), all other rpc calls presuppose that the client has first obtained a connection identifying its session. To enforce this contract, we will add a simple decorator method which we can put on the RPC methods of the Chai class in order to enforce this contract.

We only need three core functions:

• #25
• #28
• #29

The client side component of informalsystems/apalache#1855

Client-side correlate of informalsystems/apalache#1113

Requested by @informalsystems/mbt team during our check-in a few weeks back.

The idea:

Currently the CmdExecutor methods have a signature (spec:Input, aux:List[Input], config:Config) -> CmdExecutorResult, where spec is the main module of the model to check and aux are any auxiliary modules that are extended by the spec (or any of its dependencies).

However the MBT team said they would prefer if the client library took care of finding dependencies on disk and loading these up for transmission to to the server.

So we'll implement a family of methods *_from_file(spec: Path, config: Config) -> CmdExecutorResult which will search for the dependencies on the file system of the client before making the RPC call.

• #11
• Add integration test suite framework
• Wire integration tests into the CI