Always generate the version through git when possible, and encode that within
the binaries so that `catala --version` does'nt give misleading information.
Previously we used dune's builtin functionality, but that resorts to a hack at
install time which is unpleasant and doesn't work with our use of `opam
install`.
The cost is a re-linking of catala_utils and the binaries upon git commit, which
is hardly noticeable.
* 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`.
Reverts 051a64c4b1
Gasp, I only now noticed this; it should absolutely be avoided, in general (the
Docker image is expected to contain a recent repo), and in particular after
switch creation.
Switch to a newer image instead (or just remove the date constraint in FROM but
stable builds are good).
- 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
