Repository navigation
env: restore #r nuget/#r file cassé dans dotnet-interactive sur po-2027 (les 2 builds) — re-exec .NET bloquée #17361
Description
Activity
[CLAIMED] #17361 — lane myia-po-2027:CoursIA-2 — env .NET po-2027: restore #r nuget/#r file cassé dotnet-interactive (les 2 builds)
Plan
- Worktree isolé : feature/17361-dotnet-restore-po2027 sur origin/main
- Reproduire les probes mono IKVM déclarés dans le body (probes A/B/C/split/multi sous 1.0.712001 vs 1.0.617701)
- Identifier cause racine dichotomique : kernel état-trouvé vs pin cluster
- Fix applicable : repair mono-restore OU pin 1.0.617701 par défaut + ré-exec notebook test
- PR H.1/H.4 : Papermill/kernel exec + sortie réelle
Vérifications first-hand Tell c.14451 / L898 / c.1356
- git worktree list : aucun worktree 17361-*
- search 17361 in:title,body : 0 PR couvrante
- PR redélivrées : aucune (L898 + c.1356 strict)
— myia-po-2027:CoursIA-2, c.760
- added a commit that references this issue
on Sep 25, 2026 [CLAIMED] lane myia-po-2024:CoursIA-2 -- helper dotnet_preload_packages.py (RFC livrable 2), livre par PR #17828 (fix/17361-dotnet-preload-helper). paths: scripts/ci/dotnet_preload_packages.py, scripts/tests/test_dotnet_preload_packages.py
Le claim du 2026-09-22 (myia-po-2027:CoursIA-2) est perime et portait le diagnostic, pas l'outillage : le present claim ne le chevauche sur aucun fichier.
- added a commit that references this issue
on Sep 25, 2026 Mesure : le livrable 3 (conversion de masse en
#rlocal) est réfutéLivré par la lane
myia-po-2024:CoursIA-2en PR #17828 (helper + cette mesure).Le plan de l'issue supposait que
#r "nuget:" Xet#r "./_deps/X.dll"sont interchangeables. Ils ne le sont pas. Pilot surMyIA.AI.Notebooks/Search/Part2-CSP/CSP-1-Fundamentals-CSharp.ipynb— le notebook du dépôt le plus exposé (3 restores NuGet dans une seule cellule), kernel.net-csharp, pin1.0.617701, po-2024 :Bras Cellule 3 Résultat Diagnostic 0 — original 3 × #r "nuget:"19/19 OK, 14,1 s — A — converti 3 × #r "./_deps/…"16/19 (cellules 32, 34, 37) IKVM.Runtime.InternalException: Could not locate ikvm home pathC — mixte IKVM local + 2 packages image en nuget:15/19 (cellule 3 et 32-37) IKVM.Image.targets(45,9): error MSB4036: Tâche "IkvmResolveNearestRuntimeIdentifier" introuvableLe bras C explique les deux autres : les
#r "nuget:"font restaurer l'arbre IKVM complet (IKVM.MSBuildfournit la tâche queIKVM.Image.targetsinvoque ; l'imageany/any+win-x64fournit le home queIKVM.Runtimecherche au premier typejava.*). Scinder les#rcasse ce graphe.Et
IKVM.Image/IKVM.Image.runtime.win-x64ne sont pas exprimables en#rlocal : leurslib/<tfm>/ne contiennent qu'un_._.Conséquences
- Livrable 3 retiré des livrables du RFC (
docs/reference/dotnet-restore-rfc-17361.md) : pas de conversion de masse des 168 notebooks.net-csharp. - Le helper
scripts/ci/dotnet_preload_packages.pyreste livré, mais comme outil de réparation à la demande sur un notebook qui a effectivement levé l'exception — pas comme convention. - Le livrable 4 (fix upstream + bump) est désormais le seul chemin général.
- Sous-produit : le bras 0 est une 4ᵉ non-reproduction du bug (corrobore c.803/c.807 après les 3 repros de c.760). Le bug reste non déterministe et non reproduit au site le plus exposé du dépôt.
- Livrable 3 retiré des livrables du RFC (
- added a commit that references this issue
on Sep 25, 2026 [CLAIMED] lane myia-po-2027:CoursIA -- #17361 : tester l'hypothese de cause racine non exploree par le body --
DOTNET_ROOTde po-2027 pointe versC:\Users\Jesse\.dotnet(runtimes seuls, pas desdk/) ; le restore kernel passe parFSharp.DependencyManager.Nuget.dll-> hostDOTNET_ROOT-> pas de SDK -> echec avale par le bugPackageRestoreResult..ctor. Probes mono/multi/#r filesous les deux builds, avec et sans overrideDOTNET_ROOT="C:\Program Files\dotnet", puis fix garde dans l'executeur si confirme + re-exec du notebook bloquant.Le claim perime du 2026-09-22 portait le diagnostic initial ; celui de po-2024 (2026-09-25) portait
dotnet_preload_packages.py, hors de mon scope. Ce claim ne chevauche sur aucun fichier .paths: scripts/notebook_tools/dotnet_executor.py, scripts/notebook_tools/exec_dotnet_persist.py, scripts/tests/test_execute_dotnet_notebook.py
[MESURE + FIX] Cause racine isolée :
DOTNET_ROOTsans SDK — et le cache NuGet qui masque la panne. Correctif livré en PR #18310.Protocole contrôlé sur un paquet jamais caché (Figgle 0.5.1, scratchpad, ce jour) :
Bras DOTNET_ROOT Cache Résultat D1 baseline ( C:\Users\Jesse\.dotnet, pas desdk/)froid échec PackageRestoreResult..ctor— et le cache reste videD2 C:\Program Files\dotnet(SDK 9.0.317 + 10.0.400)froid succès — cache peuplé D3 baseline chaud succès (3,3 s) — le restore court-circuite Le restore
#r "nuget:"passe parFSharp.DependencyManager.Nugetqui lancedotnet restorevia le hôteDOTNET_ROOT. Sans SDK dans ce root, le restore ne peut pas s'exécuter du tout ; si le paquet est déjà en cache global, le restore court-circuite et passe — d'où la lecture « intermittente / dépendante du paquet / différente entre builds » du body (mesuré le 22/09 sans cette variable).Deux conséquences sur le body de l'issue :
- le constat « mono-restore OK sous le pin 1.0.617701 » et « multi ÉCHEC » s'explique sans la variable builds : les paquets du bras mono étaient en cache, ceux du bras multi ne l'étaient pas. Réfuté par mesure : sous le pin et l'env réparé, 2 restores à froid dans une même cellule + un 3e à la cellule suivante passent (probe G, PR body).
- la piste « comparer avec ai-01 » est close par la même cause : la différence n'est pas les versions, c'est le
DOTNET_ROOTde la machine (déjà consigné en mémoire per-machine depuis le 2026-09-06, jamais croisé avec ce constat).
Correctif (PR #18310, MED/tooling) : module feuille
_dotnet_env.py+ garde appliquée aux deux surfaces vivantes de lancement de kernel .NET (dotnet_executor.pycanonique, etnotebook_helpers.pyNotebookExecutor— qui ne peut pas importer l'executeur, d'où le module feuille). Env du subprocess kernel uniquement, jamais la variable machine. Les deux surfaces re-prouvées à froid (CliWrap purgé du cache) sous env baseline sans override manuel. La jambe#r "fichier.dll"passe aussi (probe F2).Restent ouverts : les deux sites morts/privés qui portent le même pattern (
scripts/execute_dotnet_notebook.pylegacy,_exec_bdd_csharp.py— nommés dans la PR) ; et la re-exécution C.2 des carnets laissés markdown-only par #13751 devient possible — suivi séparé.[CLAIMED-AMEND] lane myia-po-2027:CoursIA -- paths: scripts/notebook_tools/_dotnet_env.py, scripts/notebook_tools/dotnet_executor.py, scripts/notebook_tools/notebook_helpers.py, scripts/notebook_tools/tests/test_dotnet_executor.py -- scope corrige apres livraison : le module feuille est apparu pendant l'implantation (notebook_helpers ne peut pas importer dotnet_executor), et le fichier de tests canonique est scripts/notebook_tools/tests/test_dotnet_executor.py (pas scripts/tests/test_execute_dotnet_notebook.py, qui teste l'executeur legacy). PR #18310.
- added a commit that references this issue
on Sep 29, 2026 Fermeture — urne
delivered, vérifiée surorigin/mainpar ai-01 (05/10)La panne de restore
#r nuget/#r fileest expliquée (DOTNET_ROOTsans SDK, masqué par le cache NuGet) et corrigée sur main par #18310. Le module_dotnet_env.pyéquipe les deux surfaces vivantes de lancement du noyau .NET, avec 37 tests. Les deux sites restants sont des fichiers morts ou archivés, sortis du périmètre. Le point que le fil déclarait « suivi séparé » a maintenant son issue nommée, ouverte avant cette fermeture : #19245 (finir le renommage-Csharpdans 6 carnets Search et les réexécuter).
Constat (mesuré le 2026-09-22, lane myia-po-2027:CoursIA, worktree
feature/13751-search-csharp-nomenclature@ 1537978)Les notebooks
.net-csharpà#rne peuvent plus être re-exécutés localement sur po-2027, dans les deux builds de dotnet-interactive disponibles. Mesures, toutes reproduites sur probes minimaux (scratchpad, reproductibles en < 10 s chacune) :#r "nuget: X"seul (1 par cellule)#r nuget:multiples#r "file.dll"localPackageRestoreResult..ctorArgumentException)Must provide errors when succeeded is false#rde la cellule OU 2ᵉ cellule#r)In [1])Faits isolés par dichotomie
#r "nuget: IKVM, 8.15.0"seul restaure et s'exécute. Le pin n'était jamais installé sur po-2027 (divergence de la même classe que ML-3 AutoML echoue sur ai-01 : dotnet-interactive 1.0.617701 embarque Roslyn 4.12, AutoML 0.23.0 exige 4.13 #11157 sur po-2024) — corrigé ce jour :dotnet tool uninstall/install --version 1.0.617701+dotnet interactive jupyter install.IKVM.Imageest unrestorable dans les deux builds : probe mono-package#r "nuget: IKVM.Image, 8.15.0"→ échec, alors que le cache~/.nuget/packagescontient TOUTES les 8.15.0 (ikvm, ikvm.image, les 11 ikvm.image.runtime.* vérifiés un à un). Hypothèse : ses 11 dépendances multi-RID (linux-, osx-, win-*) ne passent pas le résolveur du kernel ; l'échec réel est avalé par le bugPackageRestoreResult..ctor(success=false avec liste d'erreurs vide).#r "fichier.dll"local échoue sous le pin :Search-02c-QuikGraph(aucun#r nuget:, seulement#r "QuikGraph.dll"résolu depuis le cwd) passait sous 1.0.712001, échoue sous le pin àIn [1], même erreur.dotnet restored'un csproj référençantIKVM 8.15.0réussit (1,1 s) — réseau, sources et cache OK. L'échec est propre àMicrosoft.DotNet.Interactive.PackageManagement.batch_reexecute.py --cwd notebook(garde census),notebook_tools.py executeet--cell-by-celléchouent identiquement — le bug est dans le kernel.FindCspDirwalk-up) exigent kernel-cwd = dossier du notebook — c'est le défaut denotebook_tools.py executeet l'option debatch_reexecute.py --cwd notebook; sous ce cwd l'erreur CSP passe deIn [1](DLL introuvable) àIn [2](restore IKVM.Image) — les deux pannes sont indépendantes.Contournement qualifié (RECOVERABLE-ENV, cf
docs/reference/dotnet-plotly-zero-restore.mdqui documente déjà « restore#r "nuget:"bloqué cluster-wide en Papermill headless »)La tranche #13751 (renommage Search) a été livrée markdown-only : les 6 occurrences du suffixe dans des commentaires de cellules code (CSP-1/2/3/5/6, Search-02c) restent volontairement à
-Csharppour garder les notebooks byte-exacts à leur dernier état exécuté (C.2). Elles passeront à-CSharpquand cet env sera réparé.Pistes de réparation (par coût croissant)
#r nuget:a été vérifié firsthand le 2026-07-25, kernels-runtime.md) : si ai-01 restaure IKVM.Image, différer ses versions (SDK 9/10, dotnet-interactive, NuGet.config machine).#r(le bugPackageRestoreResult..ctorvide est un bug .NET Interactive connu).#rpar le kernel (pas de piste simple identifiée).