Non détection des packages dans venv

Salon des Développeurs Aide Programmation
1

Bonjour,

J’essaye de passer mon démon python en mode ‹ venv ›, j’ai modifié le script install pour installer les packages dans le rep /resources/venv et ça semble bien se passer (log ok) Mais, depuis le code php impossible de vérifier la bonne installation, la commande donne toujours le nb de packages = 0

dans le code php:

        $deps = exec($exec, $output, $result);
        if ($deps < 4) {
            LgLog::info(sprintf("missing pip dependancies ($deps)($exec)(%s)($result)", var_export($output, true)));
            return 'nok';

donne ce log:
2440|[2023-08-20 23:33:57]INFO : missing pip dependancies (0)(/var/www/html/plugins/lgthinq/resources/venv/bin/python3 -m pip list | grep -Ec « Flask|requests »)(array ( 0 => ‹ 0 ›, ))(1)

Pourtant la même commande, quand je suis en ssh dans jeedom, renvoie bien 4 ! Je n’arrive pas à voir la différence… j’ai un warning avec www-data

image
image1585×116 34.8 KB

J’ai le même comportement sur un rpi4 ou bien dans un container docker, ça marche en ligne de commande mais pas en php :confused:

Voici le script d’install, dans la mesure où il s’exécute sans erreur et la ligne de commande semble confirmer que tout est bon, je le remet pas en cause mais alors sinon où serait le problème ?

2

Il manque le sudo
Les libs sont installés sous sudo donc tu dois vérifier avec aussi je pense.

C’est pas ta question mais dans certain cas faut faire l’upgrade de wheel en plus de pip dans le venv. J’ai déjà eu des soucis si pas fait, ça dépend des libs que tu installes bien sur.

Et ton install de python quand t’as pas la bonne version n’est pas compatible avec ton venv. Tu n’exécutes pas ma bonne version.
De toute façon c’est inutile je pense, 99% sont sous buster ou bullseye

3

Hello @pifou, @Mips,

A noter que le normalement il n’est pas nécessaire, ni vraiment recommandé d’installer le venv en root, de plus le core risque de repasser par dessus lors d’un rétablissement des drois.
Si tu n’as pas besoin de modifier le système ou d’accéder à des périphériques système, ni l’install, ni le lancement du daemon n’a besoin d’être en root, c’est malheureusement pourtant le cas sur beaucoup de daemon que je vois.

Bad

4

Je ne comprends pas ce que tu proposes.
On n’a pas le choix puisque le script d’install est executé par le core d’office avec sudo

5

Rien ne t’empêche de refaire un sudo -u www-data ma commande ensuite

1 « J'aime »
6

Alors, en effet le script d’install est exécuté en mode ‹ root › donc j’ai tenté d’ajouter le sudo pour le check_dependency mais pas mieux :

4322|[2023-08-21 22:09:24]INFO : missing pip dependancies (0)(sudo /var/www/html/plugins/lgthinq/resources/venv/bin/python3 -m pip list | grep -Ec « Flask|requests »)(array ( 0 => ‹ 0 ›, ))(1)

Mais, je ne comprends pas, puisque je teste en ssh en root (ou pi) et ça marche, et du reste avec sudo -u www-data ça marche aussi au warning près, qui ne devrait pas bloquer la commande. Par contre même si je rétablis les droits, le venv revient à www-data, ça ne marche pas mieux. Je devrais peut être forcer l’install des dépendances en mode -u www-data ?

C’est vrai, je le laissais pour les 1% de smart pas encore migrées sur buster, mais si c’est plus compatible je vais le virer.

Après, c’est vrai que je démarre le démon avec cmdSudo aussi - donc en root - si je change l’install pour ne plus être root je pourrais virer le root au daemon_start.

7

Hello,

Dans jMQTT je me souviens avoir eu des problèmes avec ce test, du coup j’ai fait comme ça :

if (!file_exists('venv/bin/pip3') || !file_exists('venv/bin/python3')) {
	self::logger('debug', "Relancez les dép, venv pas créé");
	$return['state'] = self::CLIENT_NOK;
} else {
	exec('venv/bin/pip3 freeze --no-cache-dir -r requirements.txt 2>&1 >/dev/null', $output);
	if (count($output) > 0) {
		self::logger('error', 'Relancez les déps, lib(s) manquante(s) : <br/>'.implode('<br/>', $output));
		$return['state'] = self::CLIENT_NOK;
	}
}

Et pour l’install :

sudo DEBIAN_FRONTEND=noninteractive apt-get install -y python3-venv python3-pip
sudo -u www-data python3 -m venv venv
sudo -u www-data venv/bin/pip3 install --no-cache-dir -r requirements.txt

(Toutes les commandes ont été abrégées ici pour plus de lisibilité)

→ Sachant qu’on m’a remonté qu’il y a des problèmes avec le venv quand on migre de Debian 10 à 11. Je n’ai pas encore trouvé une façon propre éviter de supprimer systématiquement le venv (car c’est un peu long à recréer), je pensais attendre 3 échec de lancement pour pb de dépendances avec au moins un lancement de l’installation des dépendances dans l’intervale, pour supprimer le venv.

Mais tu ne devrais pas avoir le pb si tu télécharges et compile ta propre version de Python (bien que je trouves ça un peu violent, volumineux et lent).

Bad

8

Moi je fais ca par exemple (indépendamment du fait qu’il soit judicieux ou pas de le faire en sudo):

exec(system::getCmdSudo() . dirname(__FILE__) . '/../../resources/venv/bin/python3 -m pip list | grep -Ec "requests +|oauthlib +|requests_oauthlib +|websocket-client +1"') < 4