Open aldbr opened 3 weeks ago
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
I created a minimal reproducer and created an issue here: https://github.com/fastapi/typer/discussions/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?
In https://github.com/DIRACGrid/diracx/pull/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
Unfortunately, dependabot
does not support conda environment https://github.com/dependabot/dependabot-core/issues/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
Here is the issue:
I have been able to reproduce the issue by downloading the latest
dirac-client
image:And executing:
Downgrading typer to
0.12.3
seems to resolve the issue: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)?