Tout part de ce besoin : avoir les caractéristiques, pour cela tu as choisi d'utiliser pyalsa, et tu cherches un moyen élégant de l'utiliser avec python3 ? Mais il est marqué python3, portage par l'auteur initial, confirmé ici aussi. J'ai probablement rien compris ! :-)
En fait, le besoin des caractéristiques des cartes audio et l'incapacité d'avoir pyalsa pour Python 3 sur ma machine m'a donné l'envie de jouer avec Python et son introspection, et m'a donné aussi le prétexte d'un journal, ce qui est déjà pas mal, ça a occupé geekement une partie de ma soirée d'hier, et ça n'a pas de prix ! :)
Alors par contre, le port de pyalsa vers Python 3 est une excellente nouvelle qui donne espoir !
Malheureusement, dans la vraie vie, je suis loin de le voir…
pyalsa est un module en C, il me faut donc le compiler pour l'utiliser avec Python 3. Ça je peux faire. Mais ce que je ne peux pas faire, c'est dire à l'utilisateur « bon en fait, pour utiliser mon logiciel interprété, il faut que tu compiles un paquet qui n'est même pas dans Sid ».
Je pourrais demander de faire du pinning ou d'utiliser les backports, mais faire dépendre mon logiciel d'une compilation manuelle… je ne peux pas. Hors mon logiciel il doit servir aujourd'hui, pas quand Debian aura intégré python3-pyalsa dans stable (dans deux ou trois ans minimum ?).
L'idée avec PyRO, même si elle a l'énorme défaut de lancer deux versions d'interpréteur différent, c'est que j'utiliserai effectivement le module pyalsa pour Python 2 directement depuis Python 3. Ainsi, quand le module python2-pyalsa est disponible chez l'utilisateur, il suffit de tomber la couche PyRO.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: PyAlsaAudio python3
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Exposer un ou des modules Python sur D-Bus [proof of concept]. Évalué à 5.
En fait, le besoin des caractéristiques des cartes audio et l'incapacité d'avoir pyalsa pour Python 3 sur ma machine m'a donné l'envie de jouer avec Python et son introspection, et m'a donné aussi le prétexte d'un journal, ce qui est déjà pas mal, ça a occupé geekement une partie de ma soirée d'hier, et ça n'a pas de prix ! :)
Alors par contre, le port de pyalsa vers Python 3 est une excellente nouvelle qui donne espoir !
Malheureusement, dans la vraie vie, je suis loin de le voir…
Pour prendre Debian comme exemple, distribution susceptible de faire tourner mon logiciel, ce ne sera pas pour Wheezy, et ce n'est pas encore pour Sid.
pyalsa est un module en C, il me faut donc le compiler pour l'utiliser avec Python 3. Ça je peux faire. Mais ce que je ne peux pas faire, c'est dire à l'utilisateur « bon en fait, pour utiliser mon logiciel interprété, il faut que tu compiles un paquet qui n'est même pas dans Sid ».
Je pourrais demander de faire du pinning ou d'utiliser les backports, mais faire dépendre mon logiciel d'une compilation manuelle… je ne peux pas. Hors mon logiciel il doit servir aujourd'hui, pas quand Debian aura intégré python3-pyalsa dans stable (dans deux ou trois ans minimum ?).
L'idée avec PyRO, même si elle a l'énorme défaut de lancer deux versions d'interpréteur différent, c'est que j'utiliserai effectivement le module pyalsa pour Python 2 directement depuis Python 3. Ainsi, quand le module python2-pyalsa est disponible chez l'utilisateur, il suffit de tomber la couche PyRO.
ce commentaire est sous licence cc by 4 et précédentes