[Python] transposition subprocess linux vers windows

[Loupsio]

Bonjour,
Je finalise actuellement un programme, il est fonctionnel sur mon pc (ubuntu) mais l'une des fonctions du programme pose probleme lorsque je le lance sous windows
il s'agit d'une fonction qui va demander à python d'executer un fichier ".R" , le reste du programme fonctionne bien aussi sous windows, mais il me renvoi une erreur lors de l'utilisation du subprocess,
voici l'erreur en question,

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Program Files\Python37\lib\tkinter\__init__.py", line 1702, in __call__
    return self.func(*args)
  File "C:\BureauCommun\GestionDeStock\GestionStock.py", line 157, in lancer_R
    subprocess.check_output(cmd,universal_newlines=True)
  File "C:\Program Files\Python37\lib\subprocess.py", line 376, in check_output
    **kwargs).stdout
  File "C:\Program Files\Python37\lib\subprocess.py", line 453, in run
    with Popen(*popenargs, **kwargs) as process:
  File "C:\Program Files\Python37\lib\subprocess.py", line 756, in __init__
    restore_signals, start_new_session)
  File "C:\Program Files\Python37\lib\subprocess.py", line 1155, in _execute_child
    startupinfo)
FileNotFoundError: [WinError 2] Le fichier spécifié est introuvable

visiblement il ne trouve pas un fichier, mais lequel? car j'ai vérifié avec un os.path.isfile(), il trouve bien le fichier a executer,
la ligne en question c'est :

subprocess.check_output(cmd,universal_newlines=True)

sachant que cmd contient :

graphique='fichier.csv'#un fichier dont aura besoin R
command= ['Rscript']
path2script= ['pathway/windows/pour/le/fichier.R']
cmd=command+path2script+graphique

j'ai vérifié avec un os.path.isfile(), il trouve bien le fichier a executer, ducoup je ne comprend pas pourquoi il ne veut pas lancer le subprocess

Merci à vous
-----

[pm42]

A la louche, je dirais que c'est parce que Linux sait exécuter n'importe quel fichier script quelque soit son suffixe s'il est exécutable et commence par un #! avec le chemin de l'interpréteur.
Alors que Windows ne sait pas le faire et qu'il faut sans doute lancer R avec comme argument le nom du script.

Ceci dit, je peux me tromper.

[Loupsio]

Salut, merci de ta réponse rapide
Je suis pas sur de comprendre, mon fichier python contient bien un shebang en debut de script pour l'executer sous linux, mais pas mon fichier R, puisque sur linux comme sur windows c'est python qui s'occupe de la partie "donner l'ordre d'executer R" avec la fonction subprocess qui est faite pour ça, en lui précisant avec quoi le lancer (d'ou le "command=['Rscript'], et le path2script qui contient l'emplacement et le nom du script à lancer) ducoup puisque linux le lance bien sans qu'il y ait de shebang dans le fichier R, windows devrait etre capable d'en faire autant, non?

[albanxiii]

Bonjour,

Hypothèse 1 :
Question bête, quand vous lancez à la main le contenu de la chaîne "cmd=command+path2script+graph ique" dans une invite de commande, est-ce qu'il se passe quelque chose ?

Hypothèse 2 :
Il peut aussi arriver qu'une fenêtre "invite de commande" apparaissent et disparaisse aussi vite une fois la commande exécutée.

[A voir en vidéo sur Futura]

[invite44510b00]

Bonjour

Ce ne serait pas un problème de path relatif au fichier csv ?
En effet, je n'ai pas la moindre idée de la façon dont se comporte linux, mais sous windows si le fichier est sur le même path que le script mais pas sur le path d'environnement de lancement du process (ici l'interpréteur R), on ne voit pas comment il pourrait le trouver.

[polo974]

et en mettant :

 path2script= [os.sep.join('pathway/windows/pour/le/fichier.R'.split('/'))]

comme ça le chemin serait windowsien ( \ au lieu de / )

car autant dans l'appel os.path.isfile(), c'est possiblement automatiquement transformé, autant dans subprocess.check_output, c'est improbable, vu que c'est un argument quelconque et non plus un path... (j'ai pas windows pour essayer, je veux pas windows, ...)

[invite44510b00]

Je ne sais pas quelle api d'accès aux fichiers utilise Python sous Windows, mais normalement un path avec des "/" au lieu des "\" ne pose pas problème (du moins avec l'API .Net).

[polo974]

python ne cause pas en .net

mais que donne la proposition que je t'ai faite? (l'important, c'est que ça marche...)

[invite44510b00]

python ne cause pas en .net

C'est partiellement faux ou, disons, incomplet.

Il existe deux implémentations de Python sur .NET :
- IronPython
- Python.Net

mais ce n'est pas le sujet.

[Loupsio]

Merci à vous,
par contre spoiler alert, ca ne marche toujours pas,
je vais répondre personne par personne, ca va etre plus simple je pense

Albanxii :

Hypothèse 1 :
Question bête, quand vous lancez à la main le contenu de la chaîne "cmd=command+path2script+g raph ique" dans une invite de commande, est-ce qu'il se passe quelque chose ?

Rien (enfin, une erreur) puisque python ne passe pas par un os.systeme(commande_comprehens ible_par_shell), concrètement "cmd" contient une liste (liste python) avec trois éléments :
['Rscript','C:\....','fichier.c sv']
par contre je viens de remarquer (peut etre est-ce normal, je ne sais pas), mais dans mon pathway j'ai bien mis des antislash "pathway\vers\le\fichier.c sv" (contrairement a ce que j'avais écrit plus haut, avec des slash normaux, mais le fichier contient bien des antislash) , par contre quand je lui demande de m'afficher "cmd" il double les antislash
c'est a dire que il transforme "pathway\vers\le\fichier.c sv" en "pathway\\vers\\le\\fichier.cs v"

Hypothèse 2 :
Il peut aussi arriver qu'une fenêtre "invite de commande" apparaissent et disparaisse aussi vite une fois la commande exécutée.

Nope, pas d'ouverture d'invite de commande (mais il me semble qu'il ne passe pas par un envoi de commande lorsqu'il passe par subprocess, contrairement a un os.system, après je ne sais pas comment il fait exactement quand il utilise subprocess)

Fustigator :

Ce ne serait pas un problème de path relatif au fichier csv ?
En effet, je n'ai pas la moindre idée de la façon dont se comporte linux, mais sous windows si le fichier est sur le même path que le script mais pas sur le path d'environnement de lancement du process (ici l'interpréteur R), on ne voit pas comment il pourrait le trouver.

Je fais pas trop la difference entre path et path d'environnement, tu veux dire le path pour accéder a l'interpreteur R?
En tout cas le path du fichier csv est le bon, (dans mon message j'avais mis des slash, mais dans mon fichier ce sont bien des antislash) j'ai copié collé directement de la barre en haut du dossier, et le fait qu'il me renvoie "True" avec le os.path.isfile() confirme que normalement c'est bon

personnellement je ne lui donne que le pathway de mon fichier, le reste est géré par subprocess grace à l'argument "Rscript" , a partir de la je pense qu'il sait ou est R sur la machine, mais dans un cas comme dans l'autre (linux et windows) je ne lui donne pas le path jusqu'a R. J'avais justement choisi cette option pour éviter les incompatibilité entre linux et windows, afin qu'il soit exportable facilement (et aussi pour passer un parametre, de python vers R)

Je ne sais pas quelle api d'accès aux fichiers utilise Python sous Windows, mais normalement un path avec des "/" au lieu des "\" ne pose pas problème (du moins avec l'API .Net).

De base c'était des antislash (vu que j'ai copié collé depuis la fenetre du dossier en question) par contre je viens de tester avec des slash, os.path.isfile() fonctionne toujours si on met des slash, mais par contre ma commande subprocess ne marche toujours pas, avec l'un comme avec l'autre


Polo974:

et en mettant :

 path2script= [os.sep.join('pathway/windows/pour/le/fichier.R'.split('/'))]

comme ça le chemin serait windowsien ( \ au lieu de / )

car autant dans l'appel os.path.isfile(), c'est possiblement automatiquement transformé, autant dans subprocess.check_output, c'est improbable, vu que c'est un argument quelconque et non plus un path... (j'ai pas windows pour essayer, je veux pas windows, ...)

Même résultat quand je lance le subprocess :

Traceback (most recent call last):
  File "C:\Program Files\Python37\lib\tkinter\__init__.py", line 1702, in __call__
    return self.func(*args)
  File "C:\BureauCommun\GestionDeStock\GestionStock.py", line 157, in lancer_R
    subprocess.check_output(cmd,universal_newlines=True)
  File "C:\Program Files\Python37\lib\subprocess.py", line 376, in check_output
    **kwargs).stdout
  File "C:\Program Files\Python37\lib\subprocess.py", line 453, in run
    with Popen(*popenargs, **kwargs) as process:
  File "C:\Program Files\Python37\lib\subprocess.py", line 756, in __init__
    restore_signals, start_new_session)
  File "C:\Program Files\Python37\lib\subprocess.py", line 1155, in _execute_child
    startupinfo)
FileNotFoundError: [WinError 2] Le fichier spécifié est introuvable

Sinon si ca ne marche vraiment pas, plutot que m'enteter avec subprocess, je pensais le lancer via une utilisation de lignes de commande shell qui seraient envoyées par python avec os.system avec un "if 'posix' " pour si on est sur linux, et un "elif 'nt' " si on est sur windows , mais le fait est que python envoi un parametre à R (le fichier csv ne sera pas le meme selon ce que choisi l'utilisateur dans l'interface python), et dans mon fichier R il y a une ligne faite pour récupérer cet argument et l'enregistrer dans une variable, sauf que si je passe par un terminal, je suis pas sur qu'on puisse envoyer un argument, il ne pourra que le sourcer avec les info déjà présentes dans le fichier .R sans recevoir d'argument externe
a moins que :

 variable_recuperee=commandArgs(trailingOnly=T)[1]

qui se trouve dans le fichier R puisse aussi recuperer un argument lorsque le code est executé en invite de commande, mais dans ce cas je ne sait pas comment passer l'argument dans l'invite de commande

[Loupsio]

EDIT,
pardon je me suis embrouillé, dans mon dernier message, le pathway dans path2script est le pathway du script R, pas le pathway du fichier csv comme j'ai pu l'ecrire juste au dessus

ducoup fustigator :

Ce ne serait pas un problème de path relatif au fichier csv ?

le pathway du csv est déja dans le script R, celui ci est bon, j'ai vérifié en ouvrant R manuellement et en copiant la ligne "setwd(pathway)" et cela fonctionne bien, meme le read.table fonctionne sans probleme,
d'ailleurs quand il y a un probleme dans le script R, ce n'est pas ce genre de message d'erreur que python renvoi, je sais plus ce qu'il dit, mais il dit clairement que c'est le script lui même qui a causé le probleme, là cela ne vient pas de ce qu'il y a dans le script R mais bien de son impossibilité à lancer le script

[albanxiii]

Re,

Vous avez peut-être déjà vu ce lien, mais au cas où je le mets quand même, le problème ressemble beaucoup au votre : https://stackoverflow.com/questions/...ess-in-windows

edit : zut, j'ai lu un peu trop vite... tant pis, je laisse quand même.

[polo974]

peut-être que le subshell ne sait pas où trouver R...

solution (pour savoir):
en python, passer la commande pour avoir la version de R (genre R -v ou R --version, voir la doc)
si l'erreur persiste, c'est que R est introuvable dans l'état dans le subshell (et donc ce ne serait pas lié aux paramètres suivants comme je l'ai cru)

[invite9dc7b526]

Ma réponse ne va peut-être pas t'aider mais moi aussi j'utilise R et un autre programme (vcftools ou samtools dans mon cas) et je pense que c'est mieux de lancer R d'abord et d'appeler les autres exécutables à partir de R, plutôt que l'inverse. C'est parce qu'au lancement, R charge un certain nombre de packages, même s'il n'en aura pas besoin, et que c'est dommage de faire ça plusieurs fois. Mais peut-être qu'il existe une façon d'invoquer une version "light" de R (?)

[Loupsio]

Effectivement quand je tape "R --version" avec python en invite de commande, il me renvoi le meme message d'erreur
et lorsque je le tape directement dans l'invite de commande, il me dit que R n'est pas reconnu en tant que commande externe ou interne,
pareil si je tape "start R" il me dit qu'il ne peut pas trouver R
Ducoup comment faire sous windows pour qu'il trouve R? il faut rajouter le chemin dans un fichier particulier pour qu'il le trouve? est ce que ca le fait a chaque fois? si on installe R sur une autre machine windows il fera la meme chose? pourquoi il ne connait pas par défaut le chemin d'un programme installé?

minuhabens,
merci du conseil, après le programme n'est pas pour mon utilisation perso et les gens de mon labo sont totalement réfractaires aux lignes de codes, quand bien meme ce serait simple d'utilisation, ducoup toute l'utilisation passe par Tkinter, donc il faut que ce soit sur python pour pas leur faire peur, et que de temps en temps, dans certains cas python fasse faire quelque chose par R (sans qu'ils le voient), l'inverse sera trop compliqué pour les gens, et comme je connais pas d'interface utilisateur type TKinter côté R...

[polo974]

peut-être en ajoutant shell=True dans check_output(...) (voir doc)

(l'indice...)

[invite44510b00]

Effectivement quand je tape "R --version" avec python en invite de commande, il me renvoi le meme message d'erreur
et lorsque je le tape directement dans l'invite de commande, il me dit que R n'est pas reconnu en tant que commande externe ou interne, .

Dans ce cas, ce n'est pas la peine d’aller plus loin; si R ne peut pas se lancer en invite de commande, il ne risque pas de se lancer via Python, sauf si on spécifie explicitement le path complet vers R.
Donc :
- vérifier si R est bien installé (donc qu'il se lance sur son path d'installation)
- ensuite, si il est installé correctement, le rajouter dans la liste des path se l'utilisateur. (vérifier via la commande "path" depuis l'invite de commande).

[Loupsio]

Cela change le message d'erreur, mais ca ne change rien d'autre

Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Program Files\Python37\lib\tkinter\__i nit__.py", line 1702, in __call__
return self.func(*args)
File "C:\BureauCommun\GestionDeStoc k\GestionStock.pyw", line 156, in lancer_R
subprocess.check_output(cmd,un iversal_newlines=True,shell=Tr ue)
File "C:\Program Files\Python37\lib\subprocess. py", line 376, in check_output
**kwargs).stdout
File "C:\Program Files\Python37\lib\subprocess. py", line 468, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['Rscript', 'C:\\path\\vers\\le\\fichier.R ', 'fichier.csv']' returned non-zero exit status 1.

Le probleme vient du fait que meme directement en ligne de commande (sans passer par python mais dans l'invite de cmd lui meme), ca ne marche pas, là ou je pense que dans le cas de la personne de l'exemple, cela devait probablement marcher en invite de commande mais pas avec le subprocess de python,

D'habitude c'est ce message que j'ai quand il y a un probleme dans le script R lui même, sauf que je l'ai testé manuellement, et que le script fonctionne,
d'ailleurs même si je lui demande de me créer un fichier texte, juste après le setwd() , il ne me le créé pas quand il est lancé avec python, donc ce n'est pas un problème dans le script, le script n'est même pas lancé, sinon la première ligne serait lue et il me créerait le fichier texte, donc en fait même avec shell=True, il ne trouve pas plus R.

[polo974]

     subprocess.check_output(cmd,un  iversal_newlines=True,shell=Tr  ue)

heu, True en un seul mot (ou bien l'espace est une erreur de copier /coller du résultat).

edit: idem pour "un iversal_newlines"

mais, bon, en effet, il vaut mieux déjà trouver R en ligne de commande... (ajouter le chemin dans le path).

[invite44510b00]

il ne trouve pas plus R.

- Vérifier dans le CP que R est bien installé .... (je sais c'est bête mais parfois ....)
- Poste le contenu de ta variable d'environnement "path"

[Loupsio]

Poste le contenu de ta variable d'environnement "path"

Je l'avais modifié la dernière fois après mon dernier message pour rajouter le path jusqu'au dossier R (il y aun fichier R.exe et R.gui dedans ainsi que quelques dossiers, si je me souviens bien), mais il fallait en fait cibler non pas le dossier R, mais le dossier R\i386 (il y a d'autres executables dedans)

ducoup problème résolu, merci a vous

PS a chaque fois qu'on installe R il faut toujours rajouter manuellement le path dans la variable d'environnement ou des fois il le met automatiquement? c'est assez lourd si on doit tout le temps tout faire manuellement sur chaque machine quand on en change

[invite9dc7b526]

puisque tu es sous ubuntu, si tu installes R avec apt install ou apt-get install en principe tu n'as pas à t'occuper du chemin d'accès. Si tu récupères les sources et que tu le compiles toi-même il faut penser à faire un make install.

[Loupsio]

oui sur ububntu on est bien d'accord, je n'ai eu aucun problème a développer le programme sous ubuntu, mais le problème c'est quand j'ai mis le programme sur windows (pour le labo) que ca a merdé, et je m'inquietais juste du fait que si ils changent de machine après mon départ, un simple copier coller du dossier avec le programme soit fonctionnel ou pas sur la nouvelle machine, (ex pc qui tombe en panne)
Parce que déjà, réinstaller R et python sur la nouvelle machine, j'ai des doutes, jamais ils ne sauront faire s'il faut en plus changer un path d'environnement c'est beaucoup trop pour le biologiste moyen

[invite9dc7b526]

Tu exagères un peu. Même un biologiste forcené peut installer R et python. Dans mon labo ils sont plusieurs à utiliser python, perl, R etc. et apparemment ça se passe bien.

[Ikhar84]

Au pire un petit script et tu ajoutes au path ce que tu veux, il y aurait plus aux biologistes qu'à double-cliquer dessus...
Sinon pour faire ça proprement, je suis sûr que ton soft sous python peut récuperer le path sous Windows, verifier que le chemin vers R y est, sinon le rajouter, cela peut être fait lors de la récuperation de l'erreur où dès le lancement du soft, l'inconvénient cette fois d'être inutilement fait à chaque lancement suivant...

En général j'utilise souvent le mecanisme des exceptions pour détecter une config insuffisante et lancer les install des outils complémentaires de facon transparente pour l'utilisateur si cela n'a pas été faite par l'installateur fait maison... au moins après on est sûr que la config est bonne et on n'a pas à compter sur l'utilisateur (principe de base...).

[Loupsio]

Oui je pense que c'est ce que je vais devoir faire, voir si il y a moyen que python recupère le path et verifie si le dossier de Rscript se trouve bien dedans, je sais pas encore comment, mais c'est un problème pour plus tard

Tu exagères un peu. Même un biologiste forcené peut installer R et python. Dans mon labo ils sont plusieurs à utiliser python, perl, R etc. et apparemment ça se passe bien.

Dans mon labo ils sont ultra réfractaires, les titulaires comme les jeunes post-doc ne touchent à rien qui soit plus avancé informatiquement que word et imageJ,
Seuls quelques doctorants vont être un peu ouvert et tenter des trucs, mais vite abandonner, quand je suis arrivé j'étais le seul à utiliser R, et maintenant quelques uns s'en servent de temps en temps depuis que j'ai fait une présentation de R devant le labo, et ses avantages sur excel, mais je suis encore le seul à m'en servir comme outil stat par défaut,
quant à python je suis le seul à utiliser, et j'ai essayé d'en parler autour de moi, l'avantage de la programmation en biologie etc... mais de ce coté la, ils sont fermé-fermé dans mon labo (avec LaTeX également ), ils utilisent les programmes que je fait parce que ca leur facilite la vie et que tant qu'il y a une interface ca va, mais au delà de ça il y à un gouffre pour eux entre la biologie et l'informatique, il ne connaissent absolument pas le principe ou même l'existence du path d'environnement.
Après ca dépend peut être des labo,

Sur ce, le programme est 100% fonctionnel sur les deux OS en l'état, merci à vous,

[pm42]

il y à un gouffre pour eux entre la biologie et l'informatique, il ne connaissent absolument pas le principe ou même l'existence du path d'environnement.

C'est étonnant et dommage de nos jours. Il y a longtemps, j'avais vu la même chose (en maths) mais ils ont vite compris.

Après ca dépend peut être des labo,

On peut l'espérer