Same source, different build environment results to different output

[NikosAlexandris]

I am not sure about the cause for the difference below :

1. Screenshot of an intentionally failing command rendered okay via either mkdocs serve --watch-theme --dirty --verbose or indeed using PDM to run the build command, i.e. pdm run mkdocs build --verbose --site-dir public.
2. Screenshot of the same failing command output built via $HOME/.local/bin/pdm run mkdocs build --verbose --site-dir public by a GitLab runner, published via GitLab Pages. The built process runs inside a standard Python 3.11 docker container.

What can be the cause for the difference?

[pawamoy]

Can you make sure you install markdown-exec with the ansi extra in the GitLab runner? markdown-exec[ansi]. Or at least confirm that pygments-ansi-color is installed (that's what the ansi extra adds).

The codes you see (\e[31m) are un-interpreted ANSI sequences 🙂

If it is present, then maybe the difference lies in the environment variables. Try exporting FORCE_COLOR=1 locally (to see if you then get the same result as CI), or unsetting it in CI (to see if you get the same result as local).

[NikosAlexandris]

Important details (maybe) this executable blocks are inside a (danger) admonition. Does it matter ?

Anyhow, I use pdm install for dependencies, both locally and in the script for the GitLab runner. So there should be difference no caused by the installation, right ? Here for reference :

ag markdown-exec pdm.lock
name = "markdown-exec"
name = "markdown-exec"
    "markdown-exec==1.8.1",

however

ag markdown-exec pyproject.toml
  "markdown-exec[ansi]",

Locally all works fine. And actually... remotely too :

  �[36m⠹�[0m Installing �[1;32mpygments-ansi-color�[0m �[33m0.3.0�[0m...                    
..
�[2K�[1A�[2K�[1A�[2K�[1A�[2K�[1A�[2K�[1A�[2K�[1A�[2K�[1A�[2K�[1A�[2K�[1A�[2K�[1A�[2K�[1A�[2K  �[32m✔�[0m Install �[1;32mpygments-ansi-color�[0m �[33m0.3.0�[0m successful

Above weird characters due to literally copy-pasting the lines from the CI log-file.

Yes, doing export FORCE_COLOR=1 locally works great. And this export is part of the script for the runner. Unsetting it in the CI, still doesn't do away the problem. I think it happens only inside admonitions or/and commands that error out. And there is one more problem in the CI : it seems the terminal width isn't fixed per line! See some uniplot example below.

Locally

GitLab runner, Python 3.11 docker image

here with an additional export COLUMNS=160

[pawamoy]

Important details (maybe) this executable blocks are inside a (danger) admonition. Does it matter ?

It shouldn't matter, no.

---

So, I'm not sure to understand how you are using markdown-exec exactly. Could you paste all relevant snippets here? The code blocks, the mkdocs.yml config, the CI config, etc. 🙂

[NikosAlexandris]

Hello, and sorry for the late reaction. I am looking at the same page in Firefox, Chrome and then Edge. In Edge it looks different (less messy). Before going for an adventurous "bug"-hunting, may the root of the problem be just the font ?

[pawamoy]

Definitely possible. Not sure how to verify though!

[NikosAlexandris]

I think the problem is indeed the lack of proper Unicode and/or font support in the CI/CD image. And related to uniplot, see also force_ascii in uniplot/tree/os-quake_keymap?tab=readme-ov-file#options -- didn't test yet. Trying to figure out how to support for Unicode in the CI/CD image I use/d which is no other than the standard Python:3.11. I can't seem to have sudo rights, at the moment, so as do something like

    - apt-get update && apt-get install -y locales
    - locale-gen en_US.UTF-8
    - update-locale LANG=en_US.UTF-8

[pawamoy]

Maybe search on the web how to install fonts in a Docker container at runtime? 🤷

[NikosAlexandris]

I also saw now : after tryint to set tome environment variable/s in the CI yaml script, then in some code blocks, in the very beginning bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8). So it must be this.