[M3devel] M3 Portabilbity, Installation, Distribution -- use Docker Containers for Easy Access?

[Olaf Wagner]

Lurking in the shadows and reading all the recent mails about improving
the build system and seeing more and more steps 'backwards' to adapt
to C, autoconf, makefiles and more overcome tools and concepts, a
heretical thought comes to mind: Have you ever considered using docker
as a means to provide easy access and distribution of Modula-3?

Some historic background: in the eighties and nineties, standardization
took place on the language level with structured programming, data types,
modules and interfaces, classes etc. I know of several attempts to extend
the new concepts and abstractions to operating system level: Smalltalk,
ELAN (extended Algol-68) (EUMEL OS ;-) and even Modula-3 come to mind
(SPIN OS). All these attempts were partially successful in their implementation,
but never succeeded in gaining even 0.01% of acceptance in the OS market.

On the OS level, however, all standardization attempts sadly failed (IMHO).
POSIX is only a crutch, and all vendors and even the free Unix derivates
and lookalikes went their own way wrt. libraries, linking and packaging.

As Greg Nelson (IIRC) mentioned to me some years ago, the aspects of
linking have never been analyzed in the scope of Modula-3, and so have
all the other OS-specific tasks like package building and distribution.
When the Modula-3 package system has been designed, there were no
Redhat or Debian packages, and perhaps only some first attempts at
SunOS packages. In the Java realm at least, packages, repositories
and build systems like maven have been largely successful, and they
look very much like a redesigned M3 build system.

Recently however, a pragmatical approach at distributing easy-to-run
software services and applications has been and still is very successful:
bundle all the needed stuff together and put it into one 'container'.
The free and most successful implementation of this is the Linux
docker system. While the implementation is ABI-centric and depends on
Linux, nontheless docker containers can be run easily on MacOS and Windows
too, which should cover more than 95% of the installation base, I think.
At Elego we've been using docker successfully for more than a year now
to automate and standardize both our development and system operation
procedures.

I haven't thought this through, but there could be several ways of using
docker together with the CM3 system. For beginners, there could be
a standalone docker image with the compiler, all packages installed,
and an HTTP-service as GUI, which would be started automatically
when running the docker image. Local directories may be mounted at
predefined locations to provide access to local files. We already
have the HTTP-service GUI in our sources!

As a development system, I could envisage a docker image with the
compiler and build system in one container image and the package libraries
-- perhaps even separated for different target architectures -- in
persistent data containers. Initial versions of the latter could also
be distributed via existing docker registries in the internet.
We would have to define something like a standard M3 docker interface
for M3 docker containers, which could be done with container entrypoints
and some additional scripts. We could use docker-compose specifications
to define complex setups.

Finally, the M3 docker system could be extended not only to run new
binaries inside its own container, but to build standalone docker
containers to run the applications and distribute them via the
existing registry system in the internet. It could all be as easy
as typing

  docker run m3-juno

to start the Juno-2 constrained based editor on your local system without
even installing one Modula-3 package or dependency. You only need to have
installed docker or one of its emulation packages.

CAVEATS

This is not for everybody and every purpose though. First, it does not
help in the realm of efficient systems programming for dedicated target
platforms. As this was one of the original goals of Modula-3 development,
it is somehow at cross-purposes with its intention.

Second, it doesn't solve the building and linking problems, but works
around them.

Third, it adds another level of complexity and probably hundreds of
MBs to running an M3 application. This seems to be more and more
acceptable, looking at other development though. ;-)

PROS

It would completely resolve the access and distribution aspect of
Modula-3 IMO. No questions anymore about how to install the compiler
and how to get it running on system X. At least, if the system X
is able to run docker containers, but as I said before, most systems
today are.

What do you think?

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194