Informations essentielles sur les scripts Python à l'intention des auteurs

Nous accueillons tous les auteurs de scripts qui souhaitent écrire des scripts pour Siril. Cependant, soutenir Siril, bien qu'amusant, prend beaucoup de temps, et nous n'avons ni le temps ni l'envie de soutenir le travail d'autres personnes en plus du logiciel principal de Siril. Il existe donc quelques directives pour garantir que la répartition des responsabilités soit claire.

  • Tous les scripts doivent afficher le nom ou le pseudonyme de l'auteur, ainsi qu'un moyen de contact (site web, chaîne YouTube, forum, etc.) où il peut être joint pour des commentaires ou des rapports de bogues. Pour les auteurs publiant de manière indépendante, il s'agit bien sûr d'une recommandation, mais pour les auteurs souhaitant publier leurs scripts via le dépôt siril-scripts, cela est obligatoire. Les scripts ne seront pas acceptés à moins que ces détails ne soient inclus.

  • Seuls les scripts open source seront acceptés dans le dépôt de scripts Siril. Les scripts à source fermée (y compris ceux comportant un wrapper de code source qui appelle un programme à source fermée) doivent être publiés de manière indépendante.

  • Les auteurs doivent également respecter les consignes de programmation des scripts figurant sur la page de l'API. Ces consignes garantissent que les scripts peuvent être utilisés par les utilisateurs finaux avec un minimum de difficultés.

Normes de codage du dépôt Siril-Scripts

En tant qu'auteur de scripts, vous pouvez écrire tous les scripts que vous voulez pour votre propre usage. Cependant, pour que des scripts soient publiés dans le dépôt siril-scripts, nous devons exiger certaines normes de codage afin de garantir qu'ils fonctionnent avec les paquets Siril standard sur chacun des trois systèmes d'exploitation pris en charge. Les exigences sont :

  • Les scripts doivent fonctionner avec des versions de Python >= 3.9. Cette version correspond à la version Python la plus ancienne de nos paquets binaires, et sera ajustée au fil du temps pour correspondre aux paquets.

  • Les scripts doivent être des scripts à fichier unique. Le dépôt a été conçu à l'origine pour les anciens scripts .SSF, et l'hypothèse d'un fichier par script demeure. Nous comprenons qu'il peut être bénéfique pour la lisibilité du code de développer des programmes python complexes en les divisant en plusieurs fichiers. C'est tout à fait acceptable lorsque vous travaillez localement, cependant les multiples fichiers devraient être combinés en un seul fichier pour la soumission au dépôt de scripts.

  • Si vous souhaitez implémenter une interface graphique dans votre script, vous devriez utiliser la boîte à outils pyQt6.

    • pyQt6 utilise le célèbre framework Qt et il a désormais été vérifié qu'il s'installe correctement depuis pypi sur toutes les plateformes prises en charge. Qt6 est bien plus rapide que Tkinter pour les scripts qui doivent eux-mêmes effectuer d'importantes manipulations graphiques, telles que des aperçus avec panoramique et zoom, et il dispose d'une agréable application de conception d'interface graphique disponible dans Qt Creator.

    Avertissement

    tkinter est désormais déprécié : les nouveaux scripts Siril ne devraient pas l'utiliser et devraient plutôt être écrits avec pyQt6. Bien que tkinter soit un module Python de base, il est dépassé, très lent, et présente des problèmes avec les bureaux Wayland sous Linux. Les scripts tkinter continueront de fonctionner tout au long de la série stable 1.4, mais il y a une quantité considérable de complexité ajoutée dans le code sirilpy pour prendre en charge tkinter. Étant donné que pyQt6 fournit une bien meilleure alternative dont il a maintenant été confirmé qu'elle fonctionne sur toutes les plateformes prises en charge par Siril, le code de support de tkinter (les sous-modules tksiril et tkfilebrowser) sera retiré au cours du cycle de développement 1.5 et sera supprimé avant la 1.6.0.

    Avertissement

    Les scripts utilisant des interfaces graphiques GTK ne seront pas acceptés dans le dépôt de scripts. Ce framework d'interface graphique nécessite des dépendances système importantes. Bien que Siril lui-même soit codé en GTK, malheureusement les paquets python gi nécessaires pour l'utiliser dans des scripts python sont cassés sous Windows et nous ne pouvons pas les inclure. Si vous le souhaitez, vous pouvez installer vous-même les dépendances et écrire des scripts utilisant GTK, et ils pourront fonctionner correctement sur votre propre machine, mais ce n'est pas pris en charge. Nous ne fournirons pas d'aide pour faire fonctionner les paquets précompilés avec des paquets non pris en charge ; si vous êtes déterminé à essayer cela, vous devrez probablement compiler Siril à partir des sources.

  • Évitez les spécifications de version d'importation qui définissent une version de paquet à l'aide de « < », « <= » ou « == ». Ces contraintes entraîneront des conflits entre les scripts, qui partagent tous le même venv. Spécifier une version de paquet à l'aide de « >= » est acceptable. N'oubliez pas d'utiliser sirilpy.ensure_installed() avant d'importer des dépendances de modules python non essentiels, afin d'automatiser leur processus d'installation.

  • Évitez d'importer des paquets nécessitant des paquets système (c'est-à-dire ceux qui ne peuvent pas être installés à l'aide de python3 -m pip install)

  • Idéalement, vérifiez que les importations de votre script s'installeront sur les trois systèmes d'exploitation cibles. Si ce n'est pas le cas, l'équipe de développement les vérifiera après soumission, et vous devrez corriger les problèmes qui surviennent.

Modules fonctionnels connus

Une liste de paquets « connus pour fonctionner », que nous avons vérifiés comme s'important sans problème, avec toutes leurs dépendances, sur tous les systèmes d'exploitation cibles, est fournie ci-dessous :

  • astropy

  • astropy-healpix

  • astroquery

  • ccdproc

  • GaiaXPy

  • matplotlib

  • numpy

  • opencv-python

  • pandas

  • photutils

  • pillow

  • pyfftw

  • pygaia

  • pyQt6

  • scipy

  • tk

  • ttkthemes

Astuce

Pour les scripts de machine learning / IA, onnxruntime est très fortement recommandé. Il est multiplateforme, indépendant du matériel, et se replie élégamment sur le support CPU si un GPU ou les bibliothèques système du GPU ne sont pas disponibles. Le sous-module sirilpy.utility fournit une classe ONNXHelper pour garantir l'installation de la version d'onnxruntime correcte selon le matériel et le système d'exploitation.

Module d'apprentissage autonome (machine learning)

Divers modules de machine learning existent et peuvent être utilisés pour écrire des scripts « IA ». Cependant, l'état du support du calcul hétérogène (c'est-à-dire l'utilisation du GPU) est inégal et nécessite souvent l'installation de bibliothèques système telles que CUDA ou ROCm. Les modules suivants sont considérés comme essentiels pour l'accélération GPU et sont soit pris en charge par des classes d'aide, soit disposent de classes d'aide en cours de développement.

  • onnxruntime - utilisé dans GraXpert et dans le script AberrationRemover.py de Riccardo, ce paquet est disponible pour tous les systèmes d'exploitation cibles. Il existe différents backends pour prendre en charge différents GPU, mais dans certains cas ceux-ci sont fragiles. Une classe d'aide ONNXHelper() est disponible pour aider à identifier et installer le paquet optimal, ainsi qu'à garantir un repli correct vers le CPU. Notez qu'actuellement sous Windows, l'ONNXHelper sélectionnera le runtime DirectML pour tous les GPU pris en charge. Même si en théorie le paquet onnxruntime-gpu basé sur CUDA pourrait être un peu plus rapide, il dépend malheureusement fortement de bibliothèques système correctement installées et configurées, et l'installation est considérée comme trop fragile pour être fiable dans le type d'environnement python automatisé utilisé par Siril. Si les utilisateurs souhaitent l'utiliser et sont confiants de pouvoir le faire fonctionner sur leur système, ils peuvent l'installer manuellement à l'aide de sirilpy.ensure_installed("onnxruntime-gpu"), mais ceci n'est pas pris en charge et les problèmes associés seront clos.

  • torch - c'est un poids lourd parmi les frameworks de ML, et alors que le support GPU était autrefois très largement basé sur CUDA, il élargit désormais sa couverture : le support des GPU NVidia et Apple Silicon est bon, et le support des GPU AMD (via ROCm) et Intel est en développement (ROCm serait suffisamment stable pour être utilisé sous Linux, mais pas encore sous Windows). Malheureusement, torch présente quelques problèmes de dépendances (il est excessivement strict sur la version de CuDNN qu'il requiert), ce qui pose des problèmes lorsqu'il est utilisé dans le même venv que d'autres modules (y compris jax - voir ci-dessous) qui font intervenir le paquet nvidia-cudnn. Une classe TorchHelper() est disponible et gère cela en installant d'abord torch, puis en le réinstallant avec l'option --no-deps, ce qui l'empêche de se plaindre si un autre paquet met à jour les dépendances vers un numéro de version supérieur. C'est vraiment peu élégant et il est regrettable que ce soit nécessaire, mais cela fonctionne. Si vous envisagez d'utiliser les versions CUDA à la fois de torch et de jax, il est préférable d'installer torch d'abord, puis jax.

  • jax - ce n'est pas un framework de ML dédié en tant que tel, mais un moyen de décharger le calcul vers le GPU. jax fournit un module en grande partie compatible avec numpy appelé jax.numpy, qui peut considérablement accélérer de nombreuses opérations de traitement de tableaux mathématiques en les déchargeant vers le GPU, et fournit également des fonctions de calcul de gradient que numpy n'offre pas. En gardant à l'esprit que la partie lente du traitement GPU est le transfert de données entre la mémoire système et la mémoire GPU, jax fournit un compilateur jit pour précompiler ses charges de travail déchargées, mais cela nécessite tout de même une conception soignée de l'algorithme pour conserver les données sur le GPU aussi longtemps que possible, ne renvoyant que le résultat final. Jax dispose d'un bon support GPU sous Linux mais seulement d'un support CPU sous Apple et Windows, bien qu'un support Metal expérimental et un support GPU Windows soient en cours de développement. Ceci n'est donc pas recommandé pour des scripts réels à l'heure actuelle, mais est mis en avant comme un framework intéressant pour développer dans un futur (espérons-le) proche, lorsque son support s'élargira. Une classe JaxHelper() est en cours de développement, qui aidera à sélectionner le bon paquet jax à installer et à tester pour confirmer qu'il fonctionne correctement.

  • Dépendances Notez que torch et jax utilisent tous deux des paquets pypi de bibliothèques GPU, de sorte que leur installation peut entraîner de très longues chaînes de dépendances - l'ensemble complet des paquets NVIDIA (CUDA, CuDNN, etc.) pèse environ 1 Go. Ainsi, lorsque vous les utilisez dans des scripts, veillez à avertir les utilisateurs qu'ils peuvent subir un téléchargement volumineux et potentiellement lent lors de la première utilisation !

Modules écartés

Évitez complètement d'utiliser les modules suivants, car ils sont connus pour causer des problèmes sur un ou plusieurs systèmes d'exploitation :

  • healpy (ne fonctionne pas sous Windows ; on peut utiliser astropy_healpix à la place)

Modules présentant des dépendances système

Les modules suivants nécessitent l'installation de paquets système qui ne peuvent pas être automatisés à l'aide de pip, et ne devraient donc pas être directement utilisés dans les scripts Siril :

  • gi (pygtk etc - nécessite l'installation d'un paquet système)

Avertissement

Nous ne pouvons pas assez insister sur le fait que de tels paquets ne sont pas pris en charge. S'ils fonctionnent pour vous localement, c'est un bonus de chance pour vous. Ils ne fonctionneront généralement avec aucun des paquets binaires précompilés (AppImage, flatpak, Windows, MacOS). Ce type de paquets n'est spécifiquement pas pris en charge et nous ne fournirons pas d'aide pour les faire fonctionner. Tous les tickets relatifs à ce type de question seront clos comme doublon de #1527.

Oui, nous savons que c'est dommage. En fait, nous aurions aimé utiliser GTK comme boîte à outils pour écrire des scripts sirilpy, mais malheureusement le wheel binaire est cassé sous Windows depuis longtemps et ne montre aucun signe d'être réparé. Nous ne pouvons pas publier une fonctionnalité essentielle qui ne fonctionne pas sur l'un des systèmes d'exploitation cibles.

Contournement pour les modules avec dépendances système

Il peut néanmoins être possible d'écrire des projets utilisant ce type de paquets, mais vous devrez les empaqueter avec leurs dépendances et les distribuer indépendamment de Siril ou du dépôt de scripts, et le module sirilpy peut toujours être utilisé pour réaliser l'intégration avec Siril. Si vous le souhaitez, vous pouvez fournir un script wrapper pouvant être distribué dans le dépôt de scripts et qui se contente d'initialiser votre programme principal. Nous n'apporterons aucune aide à ce sujet. Comme indiqué ci-dessus, l'utilisation de ces paquets dans les scripts Siril n'est pas prise en charge.

Scripts à code source fermé

L'interface python exécutera volontiers des fichiers .pyc précompilés. Siril est un logiciel libre et open source, et nous n'encourageons donc pas le développement de scripts à source fermée, mais nous ne l'interdisons pas non plus. En pratique nous ne le pouvons pas, car même les interprétations les plus strictes de la GNU Public License permettent d'écrire une couche open source qui s'intercale entre Siril et une application à source fermée. De plus, nous sommes favorables à la liberté, et bien que nous choisissions de publier Siril sous licence GPL pour offrir la liberté à nos utilisateurs, nous respectons également la liberté des développeurs de choisir comment ils publient leur propre travail.

Il y a aussi un peu d'histoire ici : Siril fournit depuis la 1.2.0 une interface intégrée vers Starnet, cependant Starnet était à l'origine open source et n'a fermé ses portes que plus tard.

Cependant, si un auteur choisit de publier un script Siril sous forme de .pyc à source fermée, il doit alors s'occuper lui-même de toutes les questions liées à sa distribution : comme nous ne sommes pas en mesure d'inspecter le code nous-mêmes pour effectuer ne serait-ce que les vérifications les plus superficielles, nous ne pouvons pas l'héberger dans le dépôt git Siril-scripts. Et bien sûr, la responsabilité du support de tels produits relève entièrement de l'auteur - l'équipe Siril n'offrira aucun conseil sur de tels produits.

Notez que les scripts doivent être compilés séparément pour chaque version de python : helloworld.py serait compilé avec python3 -m compileall helloworld.py, ce qui générerait helloworld.cpython-<version>.pyc, où <version> serait 312 pour Python 3.12, 313 pour Python 3.13 et ainsi de suite selon la version de python utilisée pour compiler le script. C'est un inconvénient inhérent aux scripts à source fermée.