Make it easy to obtain other executables
Clarification and motivation
We have scripts/morley.sh
that was developed more than a year ago when we wanted to make it easy to use our small morley
utility. We use GitLab's container registry and upload some Docker files there from CI, see https://gitlab.com/morley-framework/morley/container_registry
The script does the following:
- Automatically pulls the image from the right location and knows what to pass to
docker
itself. - Maps docker paths to paths expected by the user. E. g. if the user specifies
--contract a.tz
we need to copy it to a place visible by docker.
AFAIU that's all essential logic.
Now we have other executables: that can be useful for people other than morley
developers:
- Debugger.
-
morley-client
to which we are going to add REPL in #5 (closed).
So we want to make it easy for everyone to get these executables. Building from sources is not an attractive option. Some options I have in mind:
- Put two more executables into the Docker image that we already create. Or put two more images.
- We can extend
morley.sh
to handle these executables in addition tomorley
itself. - We can define
morley-debugger.sh
andmorley-client.sh
similar tomorley.sh
. - Maybe we can somehow make path magic unnecessary and make
./a.tz
visible todocker
. In that case maybe we won't need the wrapper script (if we assume that people know how to usedocker
) or at least will be able to simplify it.
- Build static binaries with
nix
and distribute them. The advantage is that you don't needdocker
at all and don't need to do any magic. Some problems with this approach:
- Less cross-platform. Windows most certainly won't work (dunno if it's supported by
docker
way), MacOS may require some complications. - You can't do
docker pull
if you want to update to a newer version. You need to update manually.
Acceptance criteria
It should be easy to download and use pre-built morley-debugger-console
and morley-client
. For now let's make only Linux mandatory, but it'd be nice to support at least MacOS as well (maybe later).