Retour en détail sur les nouveautés …

Le choix de l’interpréteur Python et les environnements virtuels

Depuis la version 1.8.5 il est possible de définir la commande pour lancer les scripts Python de votre package.  Par défaut chaque script était lancé avec la commande “python” ce qui vous obligez à définir la commande “python” dans le PATH de votre système.

Désormais vous pouvez définir dans le fichier App.config de votre package Python, l’attribut “pythonCmd” pour spécifier la commande à lancer. Ci-dessous un exemple avec l’interpréteur Python 2.7 :

<pythonProxy xmlns="urn:Constellation.PythonProxy" pythonCmd="C:\Python27\python.exe">
  <scripts>
    <script filename="Scripts\Demo.py" />
    <script filename="Scripts\Demo2.py" />
  </scripts>
</pythonProxy>

L’attribut “pythonCmd” peut-être également défini de manière individuelle pour chaque script. Prenez par exemple la configuration suivante :

<pythonProxy xmlns="urn:Constellation.PythonProxy" pythonCmd="python3">
  <scripts>
    <script filename="Scripts\Demo.py" />
    <script filename="Scripts\Demo2.py" pythonCmd="C:\Users\Sebastien\venv\Scripts\python.exe" />
    <script filename="Scripts\Demo3.py" pythonCmd="C:\Python27\python.exe" />
  </scripts>
</pythonProxy>

Ci-dessus le package Python démarre trois scripts Demo.py, Demo2.py et Demo3.py de la façon suivante :

• Demo.py sera lancé par l’interpréteur Python 3 (via la commande “python3” défini au niveau global)
• Demo2.py sera lancé par un environnement virtuel ici nommé “venv” (défini pour le script)
• Demo3.py sera lancé par l’interpréteur Python 2.7 installé dans “C:\Python27”

Il devient donc possible d’utiliser des interpréteurs Python spécifiques dont les environnements virtuels. Notez que si rien n’est défini, les scripts seront lancés par la commande “python”.

Le support de Python 3.x

La version 1.8.6 du Proxy Python est désormais compatible Python 2.x et Python 3.x.

Il est donc maintenant possible d’écrire des packages Constellation en Python 2.x ou en Python 3.x (ou les deux en même temps, avec ou sans environnements virtuels avec l’attribut “pythonCmd” vu précédemment).

La configuration du “Proxy” par settings Constellation

Il est possible d’utiliser des settings Constellation (c’est à dire des variables de configuration que l’on peut administrer depuis la Constellation par l’API ou la Console) dans la section de configuration de votre App.config qui défini les scripts et les interpréteurs Python à utiliser.

Pour cela, au démarrage de votre package le Proxy Python remplacera les tags au format $(xxxx) où xxxx est la clé d’un setting de votre package.

Pour bien comprendre imaginez que vous souhaitez changer l’interpréteur Python à utiliser dans les settings Constellation.

Commençons par déclarer un setting dans le manisfest de votre package que nous nommerons “PythonPath” avec la valeur par défaut “python”. Dans le fichier PackageInfo.xml :

<Settings>
  <Setting name="PythonPath" defaultValue="python" type="String" />
</Settings>

Maintenant dans la configuration de notre proxy Python définissons l’attribut “pythonCmd”, c’est à dire la commande à utiliser pour lancer nos scripts Python, par la valeur de notre setting Constellation en utilisant le tag $(PythonPath). Soit dans le fichier App.config :

<pythonProxy xmlns="urn:Constellation.PythonProxy" pythonCmd="$(PythonPath)">
  <scripts>
    <script filename="Scripts\Demo.py" />
  </scripts>
</pythonProxy>

Dans la Console Constellation, la valeur par défaut est donc “python” :

Lorsque nous démarrons le package, on peut constater dans les logs que le tag est bien remplacé par la valeur par défaut ici “python”, qui dans mon environnement est un alias vers Python 3.6.8 :

Sans changer notre cas, modifions la valeur du setting “PythonPath” depuis l’interface Web de la Console Constellation en spécifiant la valeur “C:\Python27\python.exe” :

Redémarrons notre package et on constatera dans les logs que notre script est maintenant exécuté par l’interpréteur Python 2.7.13 :

Il devient alors possible de jongler entre les différentes versions des interpréteurs Python ou même les environnements virtuels depuis les settings Constellation sans devoir toucher au package lui-même.

Utilisation des settings Constellation avant le “Start” et notification de mise à jour

Depuis vos scripts Python pour récupérer la valeur d’un setting Constellation il faut utiliser la méthode GetSetting :

Constellation.GetSetting("MonSetting")

Jusqu’à la version 1.8.6, on ne pouvait appeller cette méthode qu’après le “Start”, mais désormais vous pouvez l’utiliser juste après l’import de la libraire Constellation, par exemple :

print("Initilisation")

import Constellation

demo = Constellation.GetSetting("Demo")
demo2 = Constellation.GetSetting("Demo2") or "Sebastien"

print("Setting Test = %s" % Constellation.GetSetting("test"))
print("setting Demo = %s et Demo2 %s" % (demo, demo2))

def Start():
    print("Démarrage !")

Constellation.Start(Start);

Vous pouvez ainsi initialiser vos scripts en ayant accès aux settings de votre package Constellation.

Autre nouveauté, l’ajout de l’évènement “OnSettingsUpdated” vous permettant d’être notifié lorsque qu’une valeur d’un setting de votre package est mis à jour dans Constellation.

import Constellation

def OnSettingsUpdated():
    print("Mise à jour de mes settings depuis Constellation !!")

def Start():
    Constellation.OnSettingsUpdated = OnSettingsUpdated

Constellation.Start(Start);

Autres nouveautés

Tout d’abord les MessageCallbacks et  lesStateObjectLinks, c’est à dire les méthodes de votre code que vous déclarez pour répondre à un message ou pour suivre un StateObject sont désormais invoquées dans un thread asynchrone pour éviter de bloquer le package.

Ensuite le « Working Directory » (os.getcwd()) est maintenant le répertoire du package et non le répertoire du script Python lui-même.

Il y a eu une revue du mécanisme de ping entre le proxy .NET et la sandbox Python basé maintenant sur le temps CPU et non l’horloge système (afin d’éviter les problèmes liés au changement d’heure).

On peut également citer l’affichage de la stacktrace complète lorsqu’une exception est levée dans le dispatch d’un MessageCallback ou d’un StateObjectLink, l’ajout automatique de la section XML de configuration dans le fichier « app.config » lors de l’installation du package ou encore l’affichage des numéros de version du Proxy python et interpréteur python au démarrage des scripts.

Pour mettre à jour votre API Python, lancez simplement le gestionnaire de package NuGet !

The post Support de Python 3, des environnements virtuels et autres nouveautés de l’API Python appeared first on Constellation.

Cette mise à jour de version accompagne désormais le SDK Visual Studio ainsi que les templates du Constellation Package Tools CLI depuis la semaine dernière.

Au programme de cette nouvelle version : la description des arguments des MessageCallbacks et des types de StateObjects.

En effet, comme vous le savez déjà, pour déclarer un MessageCallback en Python il suffit d’ajouter le décorateur Constellation.MessageCallback() :

@Constellation.MessageCallback()
def MultipleParameterCallback(a, b, c):
    '''
    MessageCallback with 3 parameters
    '''
    Constellation.WriteInfo("a = %s - type: %s" % (a, type(a)))
    Constellation.WriteInfo("b = %s - type: %s" % (b, type(b)))
    Constellation.WriteInfo("c = %s - type: %s" % (c, type(c)))

Dans l’exemple ci-dessus, une méthode Python avec 3 paramètres, le simple fait d’ajouter le décorateur Constellation.MessageCallback() permet d’invoquer cette méthode depuis n’importe quel client (package ou consommateur) connecté dans notre Constellation.

D’ailleurs, ce MC est également référencé dans Constellation. Nous pouvons le découvrir sur le ControlHub ou via le MessageCallbacks Explorer de la Console Constellation :

Seulement à l’inverse de l’API .NET, les parametres d’une méthode Python (et les variables de manière globale) ne sont pas fortement typés comme en .NET. Autrement dit, il n’y a rien qui indique le type des arguments de notre MessageCallback. Côté MessageCallbacks Explorer les arguments sont alors reconnus comme « Objects ».

Cette mise à jour 1.8.4 permet la description des arguments en utilisant une syntaxe empruntée à Sphinx dans les commentaires.

Pour cela utilisez la syntaxe suivante dans la description du MC :

:param <type> <name> : <description>

Par exemple pour décrire les 3 arguments de notre exemple :

@Constellation.MessageCallback()
def Demo(a, b, c):
    '''
    Ceci est un exemple de MC avec 3 parametres

    :param int a: My int value
    :param bool b: My boolean value
    :param string c: My string value
    '''
    Constellation.WriteInfo("a = %s - type: %s" % (a, type(a)))
    Constellation.WriteInfo("b = %s - type: %s" % (b, type(b)))
    Constellation.WriteInfo("c = %s - type: %s" % (c, type(c)))

Ainsi en retournant sur le MC Explorer, chaque argument est correctement typé dans Constellation :

Notez que vous pouvez également décrire des types complexes utilisés comme type de paramètre d’entrée, définir les paramètres qui sont optionnels, ou encore décrire les types de retour.

Egalement compris dans cette mise à jour la description des types complexe utilisés comme modèle de données de vos StateObjects.

Pour en profiter il suffit de mettre à jour le package Nuget depuis Visual Studio ou de taper la commande « ctln update » si vous utilisez la CLI.

The post Décrire les MessagesCallbacks en Python avec la mise à jour du PythonProxy 1.8.4 appeared first on Constellation.

Découvrons ces nouveautés en détail !

PythonProxy 1.8.2 :  amélioration de l’expérience de développement des packages Python

Configuration des scripts à démarrer

Depuis la sortie du “PythonProxy” en décembre 2014 permettant d’embarquer des scripts Python dans un package Constellation, tous les fichiers “.py” présents dans le répertoire “Scripts” étaient chargés à l’exception du fichier “Constellation.py” et des fichiers terminant par “lib.py” ce qui permettait d’inclure des librairies Python dans vos packages. De plus tous ces fichiers Python étaient lancés par ordre alphabétique.

Cela fait désormais partie du passé ! En effet, depuis la mise à jour 1.8.2, il faut déclarer la liste des fichiers Python à charger dans le fichier App.config en ajoutant la section suivante :

<pythonProxy xmlns="urn:Constellation.PythonProxy">
  <scripts>
    <script filename="Scripts\Demo.py" />
    <script filename="Scripts\LightSensor.py" />
    <script filename="Scripts\Camera.py" />
  </scripts>
</pythonProxy>

Sans oublier de déclarer dans la section <configSection> la ligne suivante :

<section name="pythonProxy" type="Constellation.PythonProxy.PythonConfigurationSection, Constellation.PythonProxy, Version=1.8.0.0, Culture=neutral, PublicKeyToken=null" />

Vous pouvez donc maintenant définir explicitement les scripts que vous voulez lancer et dans l’ordre que vous souhaitez sans devoir jouer sur les noms des fichiers.

Cela offre plus de souplesse dans la conception de vos packages avec un fonctionnement beaucoup plus clair et explicit.

Timeout de démarrage

Lorsque le PythonProxy lance un script Python que vous avez écrit, il cherchera à se connecter avec lui avant d’invoquer votre méthode “OnStart”. Seulement en cas de problème, par exemple si votre script comporte des erreurs fatales, la connexion n’aura jamais lieu et votre package sera bloqué !

Désormais cette nouvelle version intègre la notion de “timeout” permettant de définir un temps maximal de démarrage. Si le PythonProxy ne parvient pas à se connecter à votre script dans le délai imparti, il affichera un message d’erreur et passera au script suivant sans bloquer indéfiniment.

Ce timeout peut être configuré pour chaque script avec l’attribut “startupTimeout” ou bien de manière globale.

Notez également qu’il existe un timout d’arrêt : si votre script n’est pas terminé après avoir reçu l’ordre d’arrêt dans un délai imparti, le PythonProxy mettra fin au processus Python qui l’héberge.

Par exemple :

<pythonProxy xmlns="urn:Constellation.PythonProxy" scriptStartupTimeout="20" scriptCloseTimeout="5">
  <scripts>
    <script filename="Scripts\Demo.py" startupTimeout="10" />
    <script filename="Scripts\LightSensor.py" closeTimeout="2" />
    <script filename="Scripts\Camera.py" />
  </scripts>
</pythonProxy>

Le 1er script (Demo.py) doit démarrer en moins de 10 secondes et le 2ème script (LightSensor.py) doit s’arrêter en moins de 2 secondes. Pour le reste, le temps de démarrage est de 20 secondes et 5 secondes pour l’arret.

Notez enfin que si aucune valeur n’est spécifiée (ni sur la balise <script> ni de manière globale sur la section <pythonProxy>), les valeurs par défaut sont :

• 30 secondes pour le démarrage
• 8 secondes pour l’arrêt

Redirection de la sortie et des erreurs Python sur Constellation

Avec cette nouvelle version du PythonProxy, l’ensemble du flux de sortie et d’erreur des processus Python qui hebergent vos scripts seront rédirigés vers les logs Constellation.

Autrement dit un simple “print” sera visible dans les logs Constellation mais surtout la moindre erreur, par exemple une erreur de syntaxe dans votre script empêchant son initialisation, sera remontée dans les logs Constellation vous donnant alors toutes les informations nécessaires pour sa correction.

Avec cette nouvelle version du Python Proxy, fini le côté “Black Box” lors du démarrage de vos scripts !

Surveillance de vos scripts

Il y a désormais un mécanisme de Ping/Pong entre le package Constellation et les scripts Python pour vérifier l’état de vie des deux parties. Si un processus Python ne reçoit plus de Ping reçu pendant plus de 30 secondes, il s’arrêtera automatiquement pour éviter les processus orphelins (notamment en cas de debug).

Mise à niveau

Pour en profiter il suffit de mettre à jour le package Nuget depuis Visual Studio et d’ajouter ensuite la section de configuration présentée ci-dessus dans votre fichier App.config.

Notez que tous les nouveaux projets Constellation créés avec le SDK 1.8.2 (présenté ci-dessous) sont déjà basés sur cette nouvelle version du Python Proxy, il n’y a aucune action à faire pour en profiter !

Mise à jour du SDK 1.8.2

Tout d’abord les templates des projets (C# et Python) ont été mis à jour avec les dernières versions des libraires (.NET et Python). Ainsi les nouveaux projets créés avec cette nouvelle version du SDK profiteront automatiquement des dernières versions de l’API .NET et du Python Proxy 1.8.2 décrit ci-dessus.

Lorsqu’un package est publié (en local ou directement sur un serveur Constellation), l’assistant effectuera un nettoyage de la solution avant de lancer la compilation. Cela permet de purger les fichiers qui ne sont plus utilisés dans votre package.

Autre détail fort bien utile, lorsque vous ajoutez une icone pour votre package, c’est à dire que vous ajoutez cette icone (png ou jpg) dans votre projet Visual Studio et que vous la déclarez dans le Package Manifeste, l’assistant de publication du package Constellation configuera automatique la propriété « Copy to Output directory » sur votre icone !

Suite à la sortie du Python Proxy 1.8.2, le schéma de configuration XSD de la nouvelle section <pythonProxy> décrite ci-dessus sera installée de façon à pouvoir profiter de l’IntelliSense dans Visual Studio lorsque vous éditez ce fichier.

De plus un nouvel « Item Template » nommé « Constellation Python Script » a été ajouté. Il permet de créer des scripts Constellation Python avec un template de base dans vos packages.

Dès qu’un script Constellation Python est ajouté, Visual Studio configurera automatiquement la propriété « Copy to Output directory » pour inclure votre script dans le package et ajoutera la référence de ce fichier dans la section  <pythonProxy> du fichier App.config toujours de manière automatique.

Autre : mise à jour de la Console et de la libraire .NET

Les différentes mises à jour de la Console du mois de Juin permettent de prendre en compte dynamiquement les packages uploadés via la Management API (sans devoir rafraichir la page). De plus plusieurs bugs ont été corrigés comme l’édition des settings de type boolean ou number sur les packages sans manifeste (eg. Virtual Package) ou encore un problème de la mise à jour des StateObjects qui n’étaient pas maintenus en cas de changement de page.

Aussi la libraire .NET Constellation a été mise à jour le 20 mai 2017 (1.8.2.17140) et le 29 juin (1.8.2.17178). Cela corrige un problème sur l’envoi de réponse à des sagas dans un environnement Linux/Mono et permet le déclenchement de la procédure d’arrêt (OnPreShutsown puis OnShutdown) sur les packages lancés hors sentinelle (par exemple depuis Visual Studio en phase de debug).

Retrouvez plus d’information sur le changelog.

The post Mise à jour de l’API Python et du SDK en version 1.8.2 appeared first on Constellation.