Setup-miniconda: Rüst-Minischmiede

Erstellt am 24. Sept. 2020  ·  9Kommentare  ·  Quelle: conda-incubator/setup-miniconda

Hallo @conda-incubator/setup-miniconda-team,

Ich habe https://github.com/conda-incubator/setup-miniforge erstellt, um direkt mit conda forge auf Standardeinstellungen umzugehen.

Mein Plan war es, ein Skript zu haben, das die Teile aktualisiert, die aktualisiert werden mussten, damit es diesem Repository folgt, und das Skript nur hin und wieder ausführen zu lassen, um die Dinge auf dem neuesten Stand zu halten.

Vielleicht gibt es einen besseren Weg, dies zu tun.

Die Gedanken?

question

Alle 9 Kommentare

Die Änderungen wären:

  • Ändern des standardmäßigen Miniconda-Installationsprogramms, sodass es stattdessen auf die Miniforge-Versionen verweist
  • Hardcoding conda-forge+defaults als Standardkanalkonfiguration
  • Noch etwas?

Wenn das der Fall ist, denke ich, dass es mit einem kleinen Skript leicht zu warten ist, ja. Ich für meinen Teil würde Miniforge auch Miniconda vorziehen.

Eine andere Möglichkeit wäre, installer-url und miniconda-version zu verwerfen und sie in einem einzigen Schlüssel wie conda-distribution oder so ähnlich zusammenzuführen. Dieser Schlüssel würde _magische Schlüsselwörter_ wie "miniconda", "miniforge" oder "anaconda" zulassen, die standardmäßig die neueste URL für diese Installer verwenden würden, aber auch URLs direkt akzeptieren würden (z. B. wenn Benutzer ihre benutzerdefinierten constructor möchten).

Hallo @jaimergp

Also aus deiner Liste:

Ändern des standardmäßigen Miniconda-Installationsprogramms, sodass es stattdessen auf die Miniforge-Versionen verweist

Sicher, aber ich denke, wir können die fehlerhaften Standardeinstellungen einfach entfernen (oder aktualisieren), wenn Benutzer seitdem keine neue Miniconda/Miniforge installieren. Normalerweise habe ich nur das gebündelte verwendet (das auch bei der Aktualisierung von Conda tendenziell schneller ist).

Hardcoding conda-forge+defaults als Standardkanalkonfiguration

Ja das schaffen wir

Noch etwas?

Hmmm, stellen Sie sicher, dass die Skripte die richtigen Dinge in Readmes ersetzen und vielleicht nur eine V1-, V2-(Haupt-)Version pflegen, damit wir keine Tags neu erstellen müssen.

Ich glaube, dass es wichtig ist, die Rückenkompatibilität nicht zu brechen, wie wir gesehen haben. Ich würde sagen, dass die v2-Zeile bei einem Miniconda-Standard bleiben muss, während v3 in Ordnung wäre, die Standardeinstellungen zu ändern, wenn nicht den Namen. So oder so, ich würde sagen, es ist völlig in Ordnung, nur Präfixe zu haben, zB miniforge-* und miniconda-* . Außerdem verwendet miniforge ein etwas anderes URL-Schema (zB pypy) als miniconda, also müssten wir alle ihre Spec-Bits handhaben, damit es sich reibungslos anfühlt.

Die Arbeit, die mit #98 begonnen wurde, hat darauf hingewiesen, dass wir das "Get mir einen Installer"-Spiel aufpeppen müssen, vielleicht in einen anderen Ordner mit einer Datei pro Strategie verschieben, z

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

da unsere Architekturen usw. unzusammenhängend werden.

Zu diesem Zweck wollen wir wahrscheinlich auch ein übergeordnetes, gut typisiertes Objekt der geparsten Aktionseingaben, damit wir nicht so viele String-Dinge machen ... die riesige Liste von Parametern wird langweilig und kann nur noch schlimmer werden . Ein Teil von mir möchte alles wegwerfen und das d.ts -> JSON-Schema-Ding machen, aber wir würden keine (nützlichen) Zeilennummern herausbekommen, also würde ein Teil des Wertes reduziert.

Danke für den Input @bollwyvl

Die Arbeit, die mit #98 begonnen wurde, hat darauf hingewiesen, dass wir das "Get mir einen Installer"-Spiel aufpeppen müssen, vielleicht in einen anderen Ordner mit einer Datei pro Strategie verschieben, z

Ich mag das, auf jeden Fall etwas zu tun!

Nachdem #126 landet, könnte es definitiv weitergehen. Die Arbeit wäre:

  • Entscheiden Sie sich für ein action.yml Schema, zB miniforge-version , etc.
  • füge vielleicht ein paar neue Schecks zu input.ts ,

    • zB only one of miniforge-version and miniconda-version können bereitgestellt werden

  • eine neue Datei download-miniforge.ts

    • (zunächst) ein Kopier -Pasta-Job von

    • Zweifellos gibt es Möglichkeiten, Code zwischen den beiden Dateien wiederzuverwenden, obwohl sie beispielsweise unterschiedliche Architekturen haben usw.

  • zu providers hinzufügen in installer/index.ts

    • die Reihenfolge ist immer noch ziemlich explizit, also ist es _wirklich_ egal, wohin es geht

  • Prüfung

Einmal schöne Sache: Es ist erfrischend einfach, die neuesten 30 Versionen von miniforge zu erhalten:

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

ohne URL-Scraping durchführen zu müssen. Hurra!

Ich denke, wir brauchen auch einen anderen Schlüssel, also zB:

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

Anstelle von flavor könnten wir variant oder build oder sogar construct .

Hier ist ein WIP für die oben genannten (benötigt Dokumente usw.):

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

Dies fängt an, einige der Probleme bei der Verwendung von mamba früher/mehr zu lösen... als ob Sie Mambaforge installieren würden, würde ich mir vorstellen, dass Sie mamba _verwenden_ möchten, nicht wahr? Ja, nun, JOKE'S ON YOU, es unterstützt (oder delegiert) eine Reihe von Dingen nicht, die wir verwenden, wie init . Also muss condaCommand bei der Auswahl des richtigen Befehls berücksichtigen und bedeutet, dass Sie conda Nähe haben müssen.

Der Geschwindigkeitsunterschied sieht für unsere Testfälle vernachlässigbar aus, aber es ist wahrscheinlich immer noch eine Verfolgung wert ... und ich weiß nicht, wie wir mit der fehlenden Funktionalität für micromamba umgehen werden ...

PR up (mit weiteren Tests und Dokumenten): https://github.com/conda-incubator/setup-miniconda/pull/133

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen