Skill de Mise à Jour de Version FlashInfer

Automatise la mise à jour de la version du package flashinfer-python à travers TensorRT-LLM.

Quand l'utiliser

• L'utilisateur demande de mettre à jour / bump / upgrader flashinfer
• Tâche de routine de mise à jour de dépendance pour flashinfer-python

Prérequis

Étape 0a : Déterminer le Nom d'Utilisateur GitHub

Interroger gh pour récupérer le login de l'utilisateur authentifié :

GITHUB_USERNAME=$(gh api user --jq .login)
echo "$GITHUB_USERNAME"

Si cela échoue, gh n'est pas authentifié — résoudre l'étape 0c d'abord, puis réessayer. En secours, dériver le nom d'utilisateur à partir du remote fork :

GITHUB_USERNAME=$(git remote -v | grep -E 'github\.com/[^/]+/TensorRT-LLM' \
  | head -1 | sed -E 's|.*github\.com[:/]([^/]+)/TensorRT-LLM.*|\1|')

Si aucun ne fonctionne, demander à l'utilisateur via AskUserQuestion.

Étape 0b : Vérifier le Remote Fork

Vérifier qu'un git remote pointant vers le fork de l'utilisateur de TensorRT-LLM existe :

git remote -v | grep -E 'github\.com/${GITHUB_USERNAME}/TensorRT-LLM'

Si aucun remote fork n'est trouvé, arrêter et notifier l'utilisateur :

Aucun remote fork GitHub détecté. Un fork de NVIDIA/TensorRT-LLM est requis pour pusher les branches et créer des PR.

1. Forker le repo à https://github.com/NVIDIA/TensorRT-LLM/fork
2. L'ajouter en tant que remote git :

   git remote add fork https://github.com/<GITHUB_USERNAME>/TensorRT-LLM.git

3. Relancer ce skill.

Étape 0c : Vérifier que gh CLI Est Authentifié

Ce skill utilise le GitHub CLI (gh) pour pusher les branches et ouvrir des PR. Confirmer qu'il est installé et authentifié :

gh auth status

Attendu : Logged in to github.com avec au moins le scope repo. repo couvre les pushes vers le fork de l'utilisateur et l'ouverture de PR sur NVIDIA/TensorRT-LLM, donc aucune PAT granulaire séparée n'est nécessaire.

Si gh rapporte « not logged in », instruire l'utilisateur :

gh auth login

Choisir : GitHub.com → HTTPS → s'authentifier avec un navigateur web (ou coller un PAT avec le scope repo).

Note sur GH_CONFIG_DIR : Si l'utilisateur maintient plusieurs comptes gh (ex. un compte personnel et un compte séparé pour le travail NVIDIA/TensorRT-LLM), ils peuvent pointer gh sur un répertoire de configuration non-défaut. Vérifier CLAUDE.local.md / AGENTS.md ou l'environnement pour GH_CONFIG_DIR ; si flou, demander à l'utilisateur. Lorsque défini, préfixer chaque invocation gh : GH_CONFIG_DIR=<path> gh ....

Ne pas procéder au workflow d'upgrade avant que gh auth status soit propre et le remote fork (Étape 0b) soit confirmé.

Workflow

Exécuter ces étapes dans l'ordre. Utiliser AskUserQuestion pour les choix utilisateur et WebFetch / GitHub API pour les données de release.

Étape 1 : Récupérer les Releases Disponibles depuis GitHub

Récupérer la liste des releases depuis https://github.com/flashinfer-ai/flashinfer/releases.

Utiliser WebFetch avec l'URL https://github.com/flashinfer-ai/flashinfer/releases et extraire tous les noms de tag de release et les dates. Collecter à la fois les releases stables (ex. v0.6.7) et les tags pre-release / nightly (ex. v0.7.0.dev20260401).

Alternativement, utiliser l'API GitHub via curl :

curl -s "https://api.github.com/repos/flashinfer-ai/flashinfer/releases?per_page=30" \
  | python3 -c "
import json, sys
releases = json.load(sys.stdin)
for r in releases:
    tag = r['tag_name']
    pre = ' (pre-release)' if r['prerelease'] else ' (stable)'
    date = r['published_at'][:10]
    print(f'{tag}  {date}{pre}')
"

Étape 2 : Vérifier la Version Actuelle

Lire la version actuellement épinglée depuis requirements.txt :

grep flashinfer-python requirements.txt

Format attendu : flashinfer-python==X.Y.Z

Étape 3 : Demander les Préférences de l'Utilisateur

Poser à l'utilisateur deux questions en utilisant AskUserQuestion :

1. « Préférer une dernière version nightly ? »

   • Options : « Oui, afficher les releases nightly/dev » | « Non, releases stables uniquement (Recommandé) »
   • Cela filtre la liste de releases affichée à la prochaine question.

2. « Vers quelle version flashinfer-python voulez-vous upgrader ? »

   • Présenter jusqu'à 4 versions plus récentes que la version actuelle (filtrées par la préférence nightly ci-dessus), avec la plus récente comme option recommandée.
   • Si la version actuelle est déjà la plus récente, informer l'utilisateur et arrêter.

Étape 4 : Mettre à Jour Toutes les Références de Version

Après que l'utilisateur sélectionne une version cible, mettre à jour tous ces fichiers :

Mettre à Jour les Hashes de security_scanning/poetry.lock

Le fichier poetry.lock contient les hashes SHA256 pour la wheel et sdist. Les récupérer depuis PyPI :

curl -s "https://pypi.org/pypi/flashinfer-python/NEW_VERSION/json" \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
for f in data['urls']:
    print(f'{f[\"filename\"]}  sha256:{f[\"digests\"][\"sha256\"]}')
"

Remplacer l'ancien bloc files = [...] sous [[package]] name = "flashinfer-python" avec les nouveaux noms de fichiers et hashes. Mettre aussi à jour la section [package.dependencies] si la nouvelle version a des dépendances différentes (vérifier requires_dist du JSON PyPI).

Important : Après l'édition manuelle à la fois de security_scanning/pyproject.toml et security_scanning/poetry.lock, le metadata.content-hash du lockfile devient obsolète. Le régénérer en exécutant :

cd security_scanning && poetry lock --no-update && cd ..

Cela rafraîchit le hash sans changer aucune autre version de package. Si poetry est disponible, vous pouvez alternativement utiliser poetry add flashinfer-python@NEW_VERSION dans le répertoire security_scanning/ pour mettre à jour à la fois pyproject.toml et poetry.lock automatiquement (y compris le content-hash).

Gestion spéciale des versions nightly / dev

Si l'utilisateur sélectionne une version nightly/dev (ex. 0.7.0.dev20260401) :

• Le package PyPI peut ne pas exister — vérifier d'abord avec curl -s "https://pypi.org/pypi/flashinfer-python/VERSION/json".
• Si ne pas sur PyPI, les hashes de security_scanning/poetry.lock ne peuvent pas être mis à jour. Avertir l'utilisateur et laisser un commentaire # TODO: update hashes when published to PyPI.
• Le requirements.txt peut épingler une installation git à la place : flashinfer-python @ git+https://github.com/flashinfer-ai/flashinfer.git@TAG#egg=flashinfer-python Demander à l'utilisateur quelle approche il préfère (pin PyPI vs git pin).

Étape 5 : Vérifier la Compatibilité de Version

Après la mise à jour, vérifier si du code a une logique gatée par version qui nécessite un ajustement :

grep -rn 'flashinfer.*__version__\|flashinfer.*version' \
  tensorrt_llm/ --include="*.py"

Emplacements connus avec vérifications de version :

• tensorrt_llm/_torch/speculative/interface.py — flashinfer.__version__ >= "0.6.4"

Si la nouvelle version est toujours >= la version gatée, aucune modification nécessaire. Sinon, signaler à l'utilisateur.

Étape 6 : Résumé

Afficher un résumé de tous les changements effectués :

• Ancienne version → Nouvelle version
• Fichiers modifiés (avec numéros de ligne)
• Tout avertissement (ex. les hashes poetry.lock n'ont pas pu être mises à jour pour nightly)
• Rappeler à l'utilisateur d'exécuter pip install -r requirements.txt pour tester localement
• Rappeler à l'utilisateur d'exécuter les tests unitaires pertinents :

  pytest tests/unittest/_torch/flashinfer/ -v
  pytest tests/unittest/_torch/attention/test_flashinfer_attention.py -v

Étape 7 : Commit, Push, et Créer une PR

Après que tous les fichiers soient mis à jour et vérifiés :

7a. Créer une nouvelle branche à partir du main upstream

git stash push -m "flashinfer-upgrade-wip" -- requirements.txt security_scanning/pyproject.toml security_scanning/poetry.lock ATTRIBUTIONS-Python.md
git checkout main
git pull --rebase https://github.com/NVIDIA/TensorRT-LLM.git main
git checkout -b ${GITHUB_USERNAME}/update_flashinfer_${NEW_VERSION}
git stash pop

Où GITHUB_USERNAME provient du remote fork (ex. yihwang-nv) et NEW_VERSION est la version sélectionnée (ex. 0.6.7.post3).

7b. Commit avec DCO sign-off

git add requirements.txt security_scanning/pyproject.toml security_scanning/poetry.lock ATTRIBUTIONS-Python.md
git commit -s -m "[None][chore] Update flashinfer-python from OLD to NEW

Bump flashinfer-python dependency to the latest stable release.
Updated version pins in requirements.txt, security_scanning/pyproject.toml,
security_scanning/poetry.lock, and ATTRIBUTIONS-Python.md."

7c. Pusher la branche vers le fork de l'utilisateur

Identifier le remote fork (de l'étape 0b — généralement nommé fork), puis pusher :

FORK_REMOTE=fork   # ajuster si l'utilisateur a nommé son fork remote différemment
BRANCH="${GITHUB_USERNAME}/update_flashinfer_${NEW_VERSION}"
git push -u "${FORK_REMOTE}" "${BRANCH}"

Si le push est rejeté pour des raisons d'auth, confirmer que gh auth status affiche le scope repo — gh installe un git credential helper qui réutilise son token pour les pushes HTTPS. Les utilisateurs sur un répertoire de config non-défaut doivent exporter GH_CONFIG_DIR dans le même shell.

7d. Ouvrir la PR sur NVIDIA/TensorRT-LLM

gh pr create \
  --repo NVIDIA/TensorRT-LLM \
  --base main \
  --head "${GITHUB_USERNAME}:${BRANCH}" \
  --title "[None][chore] Update flashinfer-python from ${OLD_VERSION} to ${NEW_VERSION}" \
  --body "$(cat <<EOF
## Summary
- Bump flashinfer-python from ${OLD_VERSION} to ${NEW_VERSION} (latest stable)
- Updated version pins in requirements.txt, security_scanning/pyproject.toml, security_scanning/poetry.lock, and ATTRIBUTIONS-Python.md

## Test plan
- [ ] pip install -r requirements.txt installs successfully
- [ ] pytest tests/unittest/_torch/flashinfer/ -v
- [ ] pytest tests/unittest/_torch/attention/test_flashinfer_attention.py -v
- [ ] CI pre-merge passes
EOF
)"

gh pr create affiche l'URL de la nouvelle PR en cas de succès. La rapporter à l'utilisateur.

Fichiers de Référence

Tous les fichiers qui contiennent des épingles de version flashinfer-python :

Notes

• Le setup.py contient un commentaire sur les URLs d'installation git+https — aucune épingle de version à mettre à jour là.
• Le .pre-commit-config.yaml et pyproject.toml font référence aux fichiers source flashinfer, pas aux versions — aucune modification nécessaire.
• Le submodule flashinfer/ (s'il existe) est séparé du package PyPI flashinfer-python.