Directive #! /usr/bin/python3 ignorée

En mode script avec un fichier.py
que ce soit avec une directive en tête de ce fichier

#! /usr/bin/env python3

ou

#! /usr/bin/python3

Le script et toujours executé en python 2

Une correction est elle possible ?

(Sans contourner par du shell)

@kiboost toi qui aime le python :wink:

Bonjour,
Ce n’est pas un « bug », les script python sont exécuté avec la commande python [script.py] (si l’extension est .py
Et ce n’est pas donc pas un problème python…

Donc ca sera toujours la version python mappée sur la commande python qui servira et la directive n’est pas utilisée du tout (et ne demande pas de changer ce mapping, tu vas casser des plugins)

Pour qu’elle le soit, il faudrait que le script soit 1) exécutable et que 2) tous les scripts contiennent cet entête (donc tu casses potentiellement l’existant).

Pas forcément si le plugin-script était bien fait :
1 il pourrait lire la directive
2 si pas de directive → python
3 si directive pyhton3 → python3
et la on reste compatible …

ps: tout mes scripts sont executables

Heu vu tout ce que permet le plugin script perso je trouve qu’il est plutôt bien fait déjà :innocent: :yum:

Le code est dispo tu vas nous faire un PR ?

1 « J'aime »

Bien oui parfait non !
Je ne touche pas aux plugins …

Ah la perfection :thinking: ça fait bien longtemps que je ne la cherche plus nul part :yum:

Je te taquine @olive ne le prend pas mal surtout

Hi @olive ,

Tu pourrais pe essayer en ajoutant 2 lignes dans plugins/script/core/script.class.php
image
et utiliser l’extension .py3

De toute façon, il faudra bien en sortir un jour de cette version de python obsolète.

2 « J'aime »

Bonne idée mon bon jpty.

Sinon au cas où tu voudrais éventuellement faire un PR, tu peux faire ça :

Le code du elseif python à copier/coller

        elseif (strpos($request, '.py') !== false) {
          $exe = 'python';
            // suppression des arguments de la commande (apres .py)
          $posPy = strpos($request,'.py');
          $file = trim(substr($request,0,$posPy)) .'.py';
          $f = file($file);
            // recherche si la 1ere ligne contient #! et python
          if($f !== false && strpos($f[0],'#!') !== false && strpos($f[0],'python')) {
            $posCmd = strpos($f[0],'python');
            $exe = trim(substr($f[0],$posCmd));
          }
          $request_shell = new com_shell($exe .' ' . $request . ' 2>&1');
	}
1 « J'aime »

Merci JPTY mais il est temps de prendre les choses en main

Plus de maintenance a partir de 2020 de Python 2 …
Bon cela ne veut pas dire que ça existe plus .

@Mips oui c’est pas un bug si on connais le code qui a été écrit dans le plugin on découvre la raison. Pourrait t’on se mettre 1 fois dans la peau de l’utilisateur averti qui aura lu la doc qui écrit son fichier.py en python3 (non c’est pas dit dans la doc python2.x)…

Alors pour avancer soit on corrige la doc (ça va prendre plus de temps que de corrigé le plugin avec 3 4 lignes.

Félicitation @jpty tu est le seule a avoir une attitude positive avec des solutions.

Les absents: @kiboost @Loic peut être ?

Je ne sais même pas pourquoi tu me mentionnes pour le coup; non ce n’est pas un bug car pouvoir exécuter des scripts python3 n’était pas un comportement qui était attendu, voulu au départ;
un bug est quand quelque chose ne fonctionne pas comme attendu (par le concepteur, pas par l’utilisateur).
C’est un manque, une adaptation, une évolution à faire mais ce n’est pas buggé; je n’en sais rien mais peut-être que python3 n’existait même pas quand ce code a été écrit.
mais bref, ca c’est pour la discussion sur le principe, discussion stérile et je m’en fiche qu’on soit d’accord sur ce point.

Pour le reste, vu que tu ne veux pas contribuer en « ne touchant pas au plugin » (pas très positif comme message), les utilisateurs (comme toi) continueront à vivre avec ce « missing feature »; à moins que quelqu’un d’autre ne le fasse.

Par contre tu n’as aucun droit de me juger… et je n’ai pas eu une attitude négative… (ni salviaf d’ailleurs), c’est très destructeur ce genre de remarque (donc cette dernière intervention n’a pas été très constructive pour le coup… en tout cas pas envers moi)

j’ai fait une seule intervention sur ce sujet, désolé si je n’ai pas fait de suivi rapide en servant la solution sur un plateau d’argent !
j’ai aussi un boulot et des urgences à traiter (comme me rendre aux urgences avec ma femme hier après-midi, pas de chance ca ne s’invente pas)
Dans cette intervention, j’ai apporté la cause exacte et précise du « problème », ce qui est selon moi la première étape dans la compréhension d’une situation afin de pouvoir ensuite faire la liste des possibilités qui existent.

@jpty, voici juste mon avis sur ta proposition: je ne chercherais pas à gérer dans le code à détecter si python2 ou python3 (ou autre), on le sait tous python2 est EOL et ce n’est pas tenable sur le long terme de continuer à écrire du code pour des applications qui ne sont plus maintenue: moi je serais plutôt pour

  1. passer d’office en python3 (avec un warning dans les releases notes)
    il est probable que pas mal de script continue de fonctionner parfaitement et si pas les modifs ne sont jamais très compliquées.
  2. au pire le gérer par une config global sur le plugin: par défaut python3 mais possibilité de forcer python2 pour une phase de transition (et dans quelques mois cette config disparait)

mais cela ne veut pas dire que ta proposition n’est pas bien, je la trouve juste plus compliquée à maintenir sur le long terme et aussi dans quelques mois il y aura des systèmes ou python sera d’office link à python3 car python2 ne sera même pas installé sur la machine donc voila…

1 « J'aime »

Bonjour Mips

Je n’utilise qu’un seul script en python pour le calcul azimut et élévation de la lune: PyEphem
Celle-ci existe et n’existera qu’en python 2

  • Forcer l’exécution par python3 n’est donc pas la bonne solution.
  • Le gérer par une config global au plugin n’est pas non plus une solution: certaines commandes seront en python 2 d’autre en 3

Maintenir les quelques lignes que j’ai proposé d’ajouter ne devrait pas être un pb. C’est déjà compatible python4 :innocent:

Sinon j’avais aussi proposé d’utiliser l’extension .py3

Salut

Je ne suis pas un programmeur, mais j’avais cru que la première ligne d’un programme Python était là pour justement indiquer le type de Python du programme qui suivait.

Antoine

1 « J'aime »

C’est uniquement quand la commande est exécutable et est exécutée en direct et pas en argument de python/python3.
La 1ere ligne donne le python à exécuter.

C’est vrais Antoine et c’est justement ce que jeedom ne prend pas la peine de lire …

C’est exactement cela.
Dans ce cas, n’est-il pas possible de simplement exécuter le script sans appeler python?
je n’ai pas testé via un com_shell, mais peut-être qu’il n’y a pas besoin de spécifier python ./script.py mais qu’on peut juste exécuter ./script.py comme on le ferait en bash?

Parce que qu’une app lise la première ligne du fichier pour ensuite décider quel python lancer, ce n’est justement pas le principe et commencer à parser des strings c’est un risque de créer des bugs à mon avis, et là ca sera la responsabilité de jeedom car on fait quelque chose qui n’est pas standard.

Il manque alors juste la vérification si le .py est exécutable. is_executable()

A vérifier mais il me semble que le plug-in rend le fichier exécutable à la création (770 dans le fichier Ajax de mémoire)

En tous cas a la 1ere sauvegarde faite tout repasse en -rwxrwxr-x 775

Le fichier est bien créé en 770.
La 1ère ligne avec #!/usr/bin/python3 ou #! /usr/bin/python devient obligatoire. Sinon à la sauvegarde du script:


Message identique lors de l’exécution dans une console.

Si le fichier n’est pas executable, le message d’erreur est :

Si la commande dans l’entête du fichier est incorrecte ( python4 dans mon exemple )
image

Et comme il existe des pythons sans shebang, le plugin script doit ouvrir le fichier.py pour y vérifier l’existence et lancer le fichier avec ou sans python au début de la ligne de commande.