Runtimes for the various backends are expected to be made available from their
own ecosystem. However, for convenience and to help with development
settings (where the runtime might change), as part of installing catala they are
put, in source form, into `<prefix>/lib/catala/runtime_LANG`.
When using a dev version of Catala, and using Python, one would then just have
to do `pip install <prefix>/lib/catala/runtime_python` within their venv to be
able to run their python programs.
- Use separate functions for successive passes in module `Driver.Passes`
- Use other functions for end results printing in module `Driver.Commands`
As a consequence, it is much more flexible to use by plugins or libs and we no
longer need the complex polymorphic variant parameter.
This patch leverages previous changes to use Cmdliner subcommands and
effectively specialises the flags of each Catala subcommand.
Other changes include:
- an attempt to normalise the generic options and reduce the number of global
references. Some are ok, like `debug` ; some would better be further cleaned up,
e.g. the ones used by Proof backend were moved to a `Proof.globals` module and
need discussion. The printer no longer relies on the global languages and prints
money amounts in an agnostic way.
- the plugin directory is automatically guessed and loaded even in dev setups.
Plugins are shown by the main `catala` command and listed in `catala --help`
- exception catching at the toplevel has been refactored a bit as well; return
codes are normalised to follow the manpage and avoid codes >= 128 that are
generally reserved for shells.
Update tests
but make sure to keep a consistent dune profile otherwise for `make all`,
avoiding multiple rebuilds.
This saves 30s CPU time on a `make all` that doesn't specify
`DUNE_PROFILE=release`
* Use the newer "pyproject.toml" for syntax highlighters
* Use venv for everything (previously, the pygment lexers were installed
globally, but more recent Python releases frown upon that. This will probably
be more stable in the long run...)
* Use one venv at the root of the project (`_python_venv/`) for both
pygments and the runtime
* Initialise this venv automatically from the Makefile (it should no longer be
necessary to run scattered `set_up.sh` scripts with mysterious interactions)
On the downsides, though:
* Only tested with Python 3.11 at the moment
* Need to remember to activate the venv (`. _python_venv/bin/activate`) from the
root for e.g. HTML literate output to work. A more manageable solution could
be for Catala to provide the lexers on-the-fly when calling `pygmentize`.
- fix dune compilation options: ensure both no dev failure on warnings and CI
failure on warnings (the defaults do neither of those things !)
- attempt to publish the build artifacts to github-pages, so that they could be
made more easily available and we could maybe remove the ones that are still
there from the main repo
Dune has 2 default build profiles: `dev` and `release`, which change things like warnings-as-errors, and debug in jsoo build mode.
We need to be in release mode when we generate the javascript artifacts (e.g. `make website-assets`), so the master `Makefile` had `--profile=release` for the `dune` commands building them. However, that rebuilds _the whole tree of dependencies_ in release mode, which means `make all` might rebuild everything several times, as the `release` flag is turned off and on. I had conflicting plugins that weren't rebuilt with the correct flag. And let's not imagine the `make -j` case…
This is the best solution I can think of for the time being:
- set the Makefile to use dune's `release` profile by default
- this ensure consistency and avoids surprises with e.g. bad (slower) artifacts
generated for the website
- devs can use `dune` directly when working, or set `DUNE_PROFILE` manually if
they need it
I am not sure yet about CI, though, since we want warnings-as-errors but also
useful artifacts. Might best to build twice…
The files where manually generated through Makefile rules, and
versionned (with an outdated version).
The issue was that we had:
- `dune` building Catala
- Makefiles calling `catala` to build and copy the `french_law/ocaml/law_source`
files
- then `dune` again to build `french_law`
The result was that `dune build` (without running `make` first) would
return a weird error.
The proposed solution adds ad-hoc dune rules to call the catala
binary, so that it can handle the whole pipeline correctly. If OCaml
is purely a backend, though, a simpler solution that makes us less
dependent on dune would be to handle the compilation of `french_law`
manually.
The dune rules are set to 'promote' the files so that it preserves the
fact that they are versionned (but with no confusion of the build system
about where they should come from anymore)
