chore(deps): actualiser uv.lock, dsoxlab tire désormais ansible-core - #53
Merged
Conversation
Le groupe dev dépend de dsoxlab en editable, et dsoxlab déclare ansible-core depuis sa 0.1.41 : ansible-runner pilote ansible-core par l'API officielle mais ne le tire pas en transitif, si bien que le tool installé pesait 18 Mo sans `ansible-playbook` dans son bin/, et que tout run sur un lab vm sortait en rc=127 sans que rien ne le traduise. Le lock ne l'avait jamais répercuté. Il ajoute donc ansible-core et ses dépendances de chiffrement, pour qu'un contributeur qui monte son venv local obtienne le même environnement que celui qui joue les labs. Constaté en marge d'une campagne de validation, où le lock du dépôt divergeait de sa propre déclaration. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Le groupe
devdépend dedsoxlaben editable, et dsoxlab déclareansible-coredepuis sa 0.1.41. Le lock ne l'avait jamais répercuté.La raison de cet ajout, côté dsoxlab, mérite d'être rappelée :
ansible-runnerpilote
ansible-corepar l'API officielle mais ne le tire pas en transitif.Mesuré sur une machine neuve, le tool installé pesait 18 Mo et son
bin/necontenait ni
ansibleniansible-playbook— toutdsoxlab runsur un labvmsortait alors en
rc=127, le code shell de « commande introuvable », que rien netraduisait.
Ce lock ajoute donc
ansible-coreet ses dépendances de chiffrement(
cryptography,cffi,jinja2,markupsafe,pycparser), pour qu'uncontributeur qui monte son venv local obtienne le même environnement que celui
qui joue les labs.
Comment c'est apparu
En marge d'une campagne de validation,
uv.lockdivergeait demainet j'aid'abord cru à une pollution de mes propres commandes. Vérification faite, c'est
l'inverse :
pyproject.tomldéclaredsoxlaben dépendancedev, dsoxlabdéclare
ansible-core, et le lock était simplement en retard sur sa propredéclaration.
Validation
dependencies = []côté projet ; seul le groupedevbouge. Les 84 labsavaient été rejoués verts avec exactement cet environnement.
🤖 Generated with Claude Code