Environment de développement pour pynab
#1
Bug 
Bonjour,

Merci d'avoir ressuscité nos lapins! Heart

Je souhaiterai discuter d'idées pour un environnement de développement pybab "cross-platform", car développer directement sur le Raspberry Pi n'est pas idéal: Ça "bloque" le lapin qui ne peut pas être utilisé pendant ce temps, c'est assez lent, et tout doit se faire par SSH (Je me débrouille bien avec VI, mais quand même!). Il serait idéal de pouvoir développer sur un PC standard et juste faire les tests manuels sur le Raspberry Pi. Je crois que ça a été abordé dans plusieurs topics du forum.

J'ai regardé plusieurs solutions:

  1. Utiliser QEMU pour faire tourner l'image de pynab (Voir ici: https://azeria-labs.com/emulate-raspberry-pi-with-qemu/). J'ai réussi à booter, mais QEMU ne supporte que 256MB de mémoire en émulant le CPU du Raspberry Pi, et de toute façon tout la partie hardware n'est pas émulée (pas de GPIO, etc.).
  2. Utiliser Docker qui est maintenant capable de faire tourner des images ARM sur des machines hôtes x86: J'arrive à faire fonctionner des images ARM, mais seulement architecture armv7l, pas armv6l comme le Raspberry Pi. Du coup certaines dépendances manquent car une architecture armv6l est requise dans requirements.txt. Le hardware serait aussi manquant dans cette configuration.
  3. Faire tout tourner directement sur une machine hôte x86, soit nativement soit via Docker (Docker probablement préféré pour que tout le monde utilise la même fondation). J'ai pu faire tourner le code sur mon PC, mais il y a des choses codées en dur à changer, par exemple la configuration de la base de données, ou la configuration des URLs statiques pour nabweb / Gunicorn si on utilise pas nginx.
Dans tous les cas, le hardware n'est pas disponible, et probablement difficile à émuler en bas niveau (de faux drivers GPIO / Son / autre?). Du coup il serait peut-être plus simple d'avoir un démon nabd alternatif, qui répondrait au protocole JSON mais ne communiquerait pas avec le hardware. Il pourrait même faire office d'émulateur de lapin avec une interface pour voir l'état des LEDs, activer les oreilles, le bouton, etc. Comme la plupart des communications passent par l'interface JSON de nabd les autres modules pourraient fonctionner tels quels.

Qu'en pensez-vous? Avez vous d'autres idées à ce sujet? Comment faites-vous pour développer?

Nico
Répondre
#2
(06-26-2020, 01:30 PM)nguillaumin a écrit : Qu'en pensez-vous? Avez vous d'autres idées à ce sujet? Comment faites-vous pour développer?
Mes 0,02€ sur le sujet: (pour le moment je n'ai fait que du développment de petits utilitaires 'command line' directement sur le lapin, mais...)
  • Il est clair qu'il vaut mieux avoir (c'est mon cas) un lapin de test, en plus de son lapin de production;
  • Pour le développement via SSH/Vi, il existe des outils comme iTerm2 pour macOS, ou MobaXterm pour Windows, qui facilitent bien les choses (scp via glisser/déposer, édition des fichiers sur l'hôte,...);
  • pour "booster" le lapin lui même on pourrait imaginer lui greffer un Raspberry Pi 4 plutôt qu'un Pi Zero:
     - je n'ai pas essayé mais je suppose que c'est faisable: après tout la carte Tag:tag:tag est un "hat" en termes d'architecture Raspberry Pi, et tous les Pi sont à ma connaissance compatibles au niveau GPIO (je suppose que l'on pourrait faire "sauter" la restrictiion armv6l au niveau des 'requirements' Pynab: armv7l devrait fonctionner aussi)
    - bien sûr, avec un Pi 4 à la place du Pi Zero, le lapin sera un peu boursouflé: il devra fonctionner les tripes à l'air ;-)
  • j'ai aussi regardé du coté des compatibles Pi Zero W plus puissants: le  Banana Pi M2 Zero semble intéressant, mais il faudrait tester (j'ai lu à son sujet des infos contradictoires sur la compatibilité GPIO)...

Sinon, pour les environnements hôte, hors QEMU et Docker, on peut aussi penser à la distribution Raspbian "Desktop" que je mentionnais dans ce thread: REST Api.
Même problématique pour le bypass du hardware/des drivers, où une solution serait en effet une version bouchonnée ou "émulateur" du démon nabd.
Répondre
#3
C'est possible de faire de l'émulation userland avec qemu et un petit wrapper.
C'est ce que nous faisons pour construire les images releases sur Travis.

https://github.com/nabaztag2018/pynab/bl...-image#L91
https://github.com/nabaztag2018/pynab/bl...-wrapper.c

Par ailleurs, la plupart des tests fonctionnent en local sur macOS X pour peu qu'on ait PostgreSQL, il y a juste les dépendances kaldi qui sont pénibles à installer et on peut s'en passer.
Répondre
#4
(06-27-2020, 01:55 PM)Paul a écrit : C'est possible de faire de l'émulation userland avec qemu et un petit wrapper.
C'est ce que nous faisons pour construire les images releases sur Travis.

https://github.com/nabaztag2018/pynab/bl...-image#L91
https://github.com/nabaztag2018/pynab/bl...-wrapper.c

Par ailleurs, la plupart des tests fonctionnent en local sur macOS X pour peu qu'on ait PostgreSQL, il y a juste les dépendances kaldi qui sont pénibles à installer et on peut s'en passer.

Merci, j'avais vu ça en effet. D'ailleurs je me suis demandé pourquoi qemu-arm-static était copié dans l'image, comme c'est un binaire x86 il ne peut pas fonctionner sur le Pi?

Code :
pi@nabaztag:~ $ qemu-arm-static
-bash: /usr/bin/qemu-arm-static: cannot execute binary file: Exec format error
pi@nabaztag:~ $ qemu-arm-static0
-bash: /usr/bin/qemu-arm-static0: cannot execute binary file: Exec format error


Dans tous les cas mon but est plutôt de tout faire tourner en local (nabweb + services) pour développer, ce qui est possible car comme tu l'indiques ça marche sur MacOS X, Python étant plus ou moins "cross platform". Le seul problème est nabd, que QEMU ne résout pas (comme il ne pourra pas émuler le hardware), d’où l'idée d'un nabd alternatif qui émule le lapin.
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)