Skip to content

asdf-0-20: Install asdf from its pre-compiled binary and default to 0.20 - #4

Draft
burisu wants to merge 2 commits into
mainfrom
default-to-asdf-0-20
Draft

burisu wants to merge 2 commits into
mainfrom
default-to-asdf-0-20

Conversation

@burisu

@burisu burisu commented Sep 15, 2026

Copy link
Copy Markdown

Problème

La gem installe asdf en clonant le dépôt puis en faisant git checkout v0.15.0.
Depuis la 0.16, asdf est réécrit en Go et distribué comme un binaire
pré-compilé : il n'y a plus de dépôt à cloner, plus de asdf.sh à sourcer, et
asdf update refuse maintenant de mettre à jour le binaire (« Upgrading asdf
via asdf update is no longer supported »). La version par défaut restait donc
bloquée sur la 0.15.0, la dernière version « shell ».

Ce qui change

  • asdf_version vaut désormais 0.20.0, la dernière version publiée.
  • asdf:setup installe et met à jour asdf tout seul à chaque déploiement : il
    lit la version installée avec asdf version, la compare à asdf_version, et
    si elles diffèrent télécharge l'archive de la release GitHub et en extrait le
    binaire dans #{asdf_path}/bin, en une commande et sans fichier temporaire
    (curl -fsSL <url> | tar -xzf - -C <path>/bin asdf).
  • L'architecture vient de uname -m sur le serveur cible (x86_64amd64,
    aarch64arm64). Seul Linux est supporté, et le README le dit maintenant.
  • asdf:map_bins exporte ASDF_DATA_DIR. Le binaire Go ne déduit plus son
    répertoire de données de son propre emplacement : sans cette variable, un
    asdf_path personnalisé installerait ses plugins dans ~/.asdf alors que le
    PATH pointe ailleurs.
  • Le module Capistrano::Asdf::Release porte les deux seules décisions qui
    méritent un test : l'URL de l'archive et la lecture du numéro de version.
  • La variable asdf_repository disparaît, plus rien n'est cloné. Le
    version.txt écrit à côté du clone disparaît aussi : la version installée est
    lue depuis le binaire, donc une mise à jour est détectée même si asdf a été
    installé à la main.
  • Version de la gem passée en 1.6.0.

Comment ça a été testé

  • bundle exec rake : 9 tests, 12 assertions, 0 échec, standard compris.
  • test/capistrano/test_release.rb (nouveau) : URL amd64 et arm64, refus d'une
    architecture pour laquelle asdf ne publie rien, lecture de 0.20.0 dans
    v0.20.0 (revision 150aaf0), et sortie vide qui donne nil.
  • test_map_bins.rb : un test de plus vérifie que ASDF_DATA_DIR="$HOME/.asdf"
    est bien exporté devant chaque commande distante.
  • Pas de test d'intégration : asdf:setup a besoin d'un vrai serveur. Les
    commandes distantes n'ont pas été jouées sur staging
    , c'est à vérifier au
    premier déploiement.

À savoir pour la relecture

  • Serveurs existants. #{asdf_path} contient aujourd'hui le clone git de la
    0.15. Le premier déploiement écrit le binaire Go par-dessus bin/asdf et
    laisse le reste en place : plugins/, installs/, shims/ et downloads/
    sont conservés, il n'y a donc aucun outil à réinstaller. Les résidus du clone
    (.git, lib/, asdf.sh, completions/, version.txt) deviennent inutiles
    et peuvent être supprimés à la main ; la gem n'y touche pas.
  • Le binaire est volontairement posé dans #{asdf_path}/bin, qui n'est plus un
    répertoire d'asdf depuis la 0.16, pour que asdf_path reste le seul réglage à
    connaître et que le PATH construit par map_bins ne change pas.
  • Repéré au passage, laissé hors périmètre. asdf:uninstall lance
    asdf uninstall <outil> sans version alors que la commande exige
    <name> <version> : la tâche est inopérante, avant comme après cette PR. Et
    le README documente une tâche asdf:upload_wrapper qui n'existe pas dans le
    code. Dites-moi si vous voulez un ticket pour l'un ou l'autre.

🤖 Generated with Claude Code

burisu and others added 2 commits September 15, 2026 14:08
Since 0.16 asdf ships as a Go binary instead of a tree of shell scripts,
so there is no repository to clone, nothing to source, and `asdf update`
refuses to upgrade the binary it ships as. asdf:setup now reads the
installed version from `asdf version` and, when it differs from
:asdf_version, downloads the release archive built for the architecture
`uname -m` reports and untars its single `asdf` executable into
#{asdf_path}/bin. Linux is the only supported target.

asdf:map_bins exports ASDF_DATA_DIR, which the binary no longer derives
from its own location: without it, a custom :asdf_path would hold the
binary while the plugins, the installs and the shims went to ~/.asdf,
where the PATH does not point.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@burisu burisu self-assigned this Sep 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant