typer 0.12.4 is creating issues in DIRAC/diracx/diracx-web CI pipelines

[aldbr]

Here is the issue:

diracx-demo-init-cs-1-ek2-52tlm diracx
╭───────────────────── Traceback (most recent call last) ──────────────────────╮
│ /opt/conda/bin/dirac:8 in <module>                                           │
│                                                                              │
│   5 from diracx.cli import app                                               │
│   6 if __name__ == '__main__':                                               │
│   7 │   sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])     │
│ ❱ 8 │   sys.exit(app())                                                      │
│   9                                                                          │
│                                                                              │
│ ╭────────────────────────────── locals ───────────────────────────────╮      │
│ │ app = <diracx.cli.utils.AsyncTyper object at 0x7fdd765579d0>        │      │
│ │  re = <module 're' from '/opt/conda/lib/python3.11/re/__init__.py'> │      │
│ │ sys = <module 'sys' (built-in)>                                     │      │
│ ╰─────────────────────────────────────────────────────────────────────╯      │
│                                                                              │
│ /opt/conda/lib/python3.11/site-packages/typer/main.py:327 in __call__        │
│                                                                              │
│ /opt/conda/lib/python3.11/site-packages/typer/main.py:310 in __call__        │
│                                                                              │
│ /opt/conda/lib/python3.11/site-packages/typer/main.py:349 in get_command     │
│                                                                              │
│ /opt/conda/lib/python3.11/site-packages/typer/main.py:331 in get_group       │
│                                                                              │
│ /opt/conda/lib/python3.11/site-packages/typer/main.py:494 in                 │
│ get_group_from_info                                                          │
│                                                                              │
│ /opt/conda/lib/python3.11/site-packages/typer/main.py:486 in                 │
│ get_group_from_info                                                          │
│                                                                              │
│ /opt/conda/lib/python3.11/site-packages/typer/main.py:580 in                 │
│ get_command_from_info                                                        │
│                                                                              │
│ /opt/conda/lib/python3.11/site-packages/typer/main.py:556 in                 │
│ get_params_convertors_ctx_param_name_from_function                           │
│                                                                              │
│ /opt/conda/lib/python3.11/site-packages/typer/main.py:845 in get_click_param │
╰──────────────────────────────────────────────────────────────────────────────╯
AssertionError: List types with complex sub-types are not currently supported

I have been able to reproduce the issue by downloading the latest dirac-client image:

$ docker run -it ghcr.io/diracgrid/diracx/client:dev /bin/bash

And executing:

$ dirac internal generate-cs /cs_store/initialRepo
AssertionError: List types with complex sub-types are not currently supported

Downgrading typer to 0.12.3 seems to resolve the issue:

$ micromamba config append channels conda-forge
$ micromamba install typer==0.12.3

I will try to check what were the latest changes included in 0.12.4.

I just have a question related to the update of the dependencies: right now we don't "freeze" the versions of the dependencies, is there any good reason? Updates are done automatically, but if there is a failure like we have now we need to identify which dependency update is the source of the issue and all the CI pipelines fail.

What about freezing the versions of the dependencies and letting a bot updating them (e.g. dependabot)?

[fstagni]

This is seen of course also in diracx: https://github.com/DIRACGrid/diracx/actions/runs/10490376700/job/29056968669?pr=281

We can freeze the version in the environment.yml until it is fixed

[aldbr]

I created a minimal reproducer and created an issue here: fastapi/typer#943.
Let's see how it goes.

In the meantime, as you said, may be the easiest solution would be to freeze the version in environment.yml.
IIUC, it should be done both in diracx and in container-images, shouldn't it?

[fstagni]

In #281 I fixed environment.yml for diracx. I think we should also fix container-images and re-create the images, because right now the integration tests are failing, e.g. https://github.com/DIRACGrid/diracx/actions/runs/10491863351/job/29061991331?pr=281#step:6:442

[chaen]

Unfortunately, dependabot does not support conda environment dependabot/dependabot-core#2227

Setting upper bound can turn into a nightmare (https://iscinumpy.dev/post/bound-version-constraints/) and fixed version is unmanageable, so we ended up with this idea of letting the test always run the latest and fail, while production version are pinned

https://github.com/DIRACGrid/diracx/blob/main/docs/TESTING.md and https://github.com/DIRACGrid/diracx/blob/main/docs/VERSIONING.md for details