arnaudlevy/quentin.dufour.io
1
0
Fork 0
forked from quentin/quentin.dufour.io
Code Pull requests 1 Activity

Update Article “2023-04-12-un-outil-sans-daemon-pour-gérer-ses-artefacts-de-build”

Browse source
This commit is contained in:
Quentin 2023-04-13 08:31:13 +00:00
parent fddeb0c9c8
commit 2799592ec5
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
_posts/2023-04-12-un-outil-sans-daemon-pour-gérer-ses-artefacts-de-build.md
View file

@ -226,7 +226,7 @@ Déjà le préfix de chemin `_releases` ne fait plus sens dans notre cas : il é
Pour autant, garder un préfixe, ça a du sens, parce qu'il va décrire comment la hiérarchie sous-jacente va se constituer, ainsi que de permettre de migrer plus tard vers de nouvelles hiérarchies. Pour autant, garder un préfixe, ça a du sens, parce qu'il va décrire comment la hiérarchie sous-jacente va se constituer, ainsi que de permettre de migrer plus tard vers de nouvelles hiérarchies.
Se pose aussi la question du triple LLVM, c'est ce qui est utilisé par Rust, mais ce n'est jamais ce qu'on affiche, à la place on utilise la notation du projet Go, notation aussi utilisée par le projet Docker. Au passage, je la trouve plus simple à comprendre car elle ne contient qu'une combinaison d'un OS et d'une architecture. Mais se pose aussi la question de ce qui se passe si on prévoit de supporter une combinaison qui n'existe pas pour Go. Et en même temps, la notation LLVM est complexe à lire et contient des informations que je considère comme des détails internes : ainsi notre choix d'utiliser musl est lié à notre choix de compiler en interne, qui est lié à l'idée qu'une fois l'OS et l'architecture identifiée, on veut que Garage tourne. Bref, tout ça me fait penser qu'on devrait adopter la notation de Go dans une démarche de penser à l'utilisateur final. Se pose aussi la question du triple LLVM, c'est ce qui est utilisé par Rust, mais ce n'est jamais ce qu'on affiche, à la place on utilise la notation du projet Go, notation aussi utilisée par le projet Docker. Au passage, je la trouve plus simple à comprendre car elle ne contient qu'une combinaison d'un OS et d'une architecture. Mais se pose aussi la question de ce qui se passe si on prévoit de supporter une combinaison qui n'existe pas pour Go. Et en même temps, la notation LLVM est complexe à lire et contient des informations que je considère comme des détails internes : ainsi notre choix d'utiliser musl est lié à notre choix de compiler en interne, qui est lié à l'idée qu'une fois l'OS et l'architecture identifiée, on veut que Garage tourne. Bref, tout ça me fait penser qu'on devrait adopter la notation de Go dans une démarche de penser à l'utilisateur final. Et si ça pose problème, il sera toujours temps de spécifier un `df-dist-v2`.
Donc on pourrait avoir ces URL : Donc on pourrait avoir ces URL :