Setup-miniconda: Configuration-miniforge

Les changements seraient :

• Modification du programme d'installation par défaut de Miniconda afin qu'il pointe plutôt vers les versions de Miniforge
• Codage en dur conda-forge+defaults comme configuration de canal par défaut
• Rien d'autre?

Si c'est le cas, je suppose que c'est facile à maintenir avec un petit script, oui. Pour ma part, je préférerais également Miniforge à Miniconda.

Une autre option serait de déprécier installer-url et miniconda-version et de les fusionner en une seule clé comme conda-distribution ou quelque chose comme ça. Cette clé autoriserait les _mots-clés magiques_ tels que "miniconda", "miniforge" ou "anaconda", qui utiliseraient par défaut la dernière URL pour ces programmes d'installation, mais accepterait également les URL directement (par exemple, si les utilisateurs souhaitent utiliser leur constructor personnalisé

Salut @jaimergp

Donc dans ta liste :

Modification du programme d'installation par défaut de Miniconda afin qu'il pointe plutôt vers les versions de Miniforge

Bien sûr, mais je pense que nous pouvons simplement supprimer les paramètres par défaut (ou les mettre à jour) lorsque les utilisateurs n'installent pas de nouveau miniconda/miniforge depuis. En général, je viens d'utiliser celui fourni (qui a tendance à être plus rapide même avec la mise à jour de conda).

Codage en dur conda-forge+defaults comme configuration de canal par défaut

Ouais on peut faire ça

Rien d'autre?

Hmmm assurez-vous que les scripts remplacent les bonnes choses sur les fichiers readme et conservez peut-être simplement une version V1, V2 (majeure) afin que nous n'ayons pas besoin de recréer les balises.

J'ai l'impression que ne pas rompre le back-compat est important, comme nous l'avons vu. Je dirais que la ligne v2 doit rester avec une valeur par défaut miniconda, tandis que la v3 conviendrait de modifier les valeurs par défaut, sinon le nom. Quoi qu'il en soit, je dirais qu'il n'y a rien de mal à n'avoir que des préfixes, par exemple miniforge-* et miniconda-* . De plus, miniforge utilise un schéma d'URL légèrement différent (par exemple pypy) de celui de miniconda, nous aurions donc besoin de gérer tous leurs bits de spécification pour le rendre fluide.

Le travail commencé sur #98 a souligné que nous devions renforcer le jeu « me procurer un installateur », peut-être le déplacer vers un autre dossier avec un fichier par stratégie, par exemple

download/
  base.ts
  file.ts
  custom.ts
  miniforge.ts
  miniconda.ts

au fur et à mesure que nos architectures, etc. deviendront disjointes.

À cette fin, nous voulons probablement aussi un objet de niveau supérieur et bien typé des entrées d'actions analysées afin que nous ne fassions pas autant de choses sur les chaînes ... la liste géante de paramètres devient fastidieuse et ne peut qu'empirer . Une partie de moi veut tout jeter et faire le schéma d.ts -> JSON, mais nous n'obtiendrions pas de numéros de ligne (utiles), donc une partie de la valeur serait réduite.

Merci pour la contribution @bollwyvl

Le travail commencé sur #98 a souligné que nous devions renforcer le jeu « me procurer un installateur », peut-être le déplacer vers un autre dossier avec un fichier par stratégie, par exemple

J'aime ça, certainement quelque chose à faire!

Après les terres n°126, cela pourrait définitivement avancer. Le travail serait :

• décider d'un plan action.yml , par exemple miniforge-version , etc.
• peut-être ajouter de nouveaux chèques à input.ts ,
  
  
  
  • par exemple only one of miniforge-version and miniconda-version peut être fourni
  
  
• un nouveau fichier download-miniforge.ts
  
  
  
  • (initialement) un travail de copie-pâte de download-miniconda.ts
  
  
  • il existe sans aucun doute des moyens de réutiliser le code entre les deux fichiers, bien que, par exemple, ils aient des architectures différentes, etc.
  
  
• ajouter à providers en installer/index.ts
  
  
  
  • l'ordre est toujours assez explicite, donc peu importe où il va
  
  
• test

Une fois une bonne chose : c'est d'une simplicité rafraîchissante d'obtenir les 30 dernières versions de miniforge :

https://api.github.com/repos/conda-forge/miniforge/releases

sans avoir à faire de grattage d'URL. Hourra !

Je pense que nous aurons également besoin d'une autre clé, donc par exemple :

use:
  miniforge-version: *
  miniforge-flavor: Mambaforge-pypy3  # `Miniforge3` default 

Au lieu de flavor nous pourrions avoir variant ou build ou même construct .

Voici un WIP pour ce qui précède (besoin de documents, etc.) :

https://github.com/bollwyvl/setup-miniconda/pull/2

Cela commence à résoudre certains des problèmes liés à l'utilisation de mamba plus tôt/plus... comme si vous installiez Mambaforge, j'imagine que vous voudriez _utiliser_ mamba , non ? Ouais, eh bien, JOKE'S ON YOU, il ne prend pas en charge (ou ne délègue de manière transparente) un certain nombre de choses que nous utilisons comme init . Donc, condaCommand doit en tenir compte lors de la sélection de la commande appropriée à utiliser, ce qui signifie que vous devez disposer de conda .

La différence de vitesse semble négligeable pour nos cas de test, mais cela vaut probablement la peine d'être poursuivi... et je ne sais pas comment nous allons gérer la fonctionnalité manquante pour micromamba ...

PR up (avec plus de tests et de documents): https://github.com/conda-incubator/setup-miniconda/pull/133