Alpha core 4.5

Bonjour,

Meme si la version est la depuis un certain temps nous avons mis les nouveautés dedans qu’a l’instant. Ca sera une grosse version du core (d’ou 4.5). Dans les nouveautés marquante il y a :

  • suppression de l’ancien système de cache (et donc des dépendances composer de celui-ci)
  • suppression des dépendances composer GitHub et webdav (aucune perte de fonction au niveau du core tout a été refait maison)
  • Mise en place d’un système de queue (en beta pour le moment), qui permet de crée des queue de traitement. Pour le moment le système est très simpliste toute les minutes il regarde toute les queues et lance l’élément le plus vieux de chacune des queues. Une fois ce fonctionnement valider il sera bien sur améliorer pour éviter le délai d’attente de 1 minutes entre chaque traitement d’un élément de la queue.
  • Passage des scénarios en mode instanciation. Avant si vous aviez plusieurs lancement simultané d’un meme scénario les tags pouvaient se marcher dessus (si ils étaient different), ce n’est plus le cas maintenant. Vous avez aussi maintenant plus de tags et surtout un tag pour avoir la valeur de la commande qui a déclenchée le scénario au moment du lancement du scénario. Le changelog ainsi que la doc explique tout cela.

Voila pour les changements majeur pour le moment (il y en a d’autre et je vous laisse consulter le changelog complet). Dans la suite prévu pour cette version ca sera de s’attaquer a la partie composer ou l’idée est de réduire le nombre de lib utiliser et surtout de virer le dossier vendor du GitHub pour faire une installation propre des dépendances composer lors de la mise a jour du core ou de l’installation (déjà le cas en Debian 12). Dans cette optique pouvez vous me dire ce que vous utilisez comme lib composer du core :

{
  "require": {
    "dragonmantank/cron-expression": "^3.3",
    "symfony/expression-language": "^5.4",
    "monolog/monolog": "^2.9",
    "pragmarx/google2fa-qrcode": "^3.0",
    "abbadon1334/sun-position-spa-php": "^2.0",
    "league/oauth2-client": "~2.3",
    "bacon/bacon-qr-code": "^2.0",
    "guzzlehttp/guzzle" : "^6.5.8",
    "http-interop/http-factory-guzzle": "^1.2",
    "symfony/http-client": "^7.0",
    "nyholm/psr7": "^1.8"
  },
  "config": {
      "allow-plugins": {
          "php-http/discovery": true
      }
  }
}

Dans celle que je pense inutile (pour le core, faut encore que je valide une a une) il y a :

    "abbadon1334/sun-position-spa-php": "^2.0",
    "league/oauth2-client": "~2.3",
    "guzzlehttp/guzzle" : "^6.5.8",
    "http-interop/http-factory-guzzle": "^1.2",
    "symfony/http-client": "^7.0",
    "nyholm/psr7": "^1.8"
7 « J'aime »

je pense qu’il ne me reste que ca (mais que du coup je peux prévoir de charger dans le plugin qui en a besoin):

  • guzzlehttp/guzzle
  • nyholm/psr7
  • league/oauth2-client

je pensais utiliser celles-ci mais je ne retrouve plus de trace:

  • symfony/http-client
  • monolog/monolog

Salut,

La nouvelle gestion du cache ne sera pas déjà effective en 4.4.10 ? On en avait discuté sur un autre fil, notamment du lifetime. Ou alors, l’ancien système de cache sera encore présent en 4.4.10 mais aussi le nouveau et l’ancien sera supprimé en 4.4.11 ?

La queue, c’est une FIFO de tâches (commandes shell, … ?) à effectuer ?
C’est dans le but de lisser la charge du système ?

A+
Michel

Si tu peux je veux bien, monologuai le core l’utilise donc je dois le garder.

Bonjour,
En 4.4.10 il y a l’ancien cache (par défaut) et le nouveau configurable en beta en 4.4.11 il n’y a plus que le nouveau

Pour le système de queue non c’est pas pour ca c’est une demande pro aucune idée de pourquoi.

Hello,

J’utilise

guzzlehttp/guzzle

Soit j’utilise Curl ou sauf si vous avez autre choses que Jeedom utilise que je n’ai pas vu ?

Cordialement

Bonjour
Tu as la class com_http qui est fait pour avec retry et tout.

1 « J'aime »

le problème de guzzle (dont j’aimerais bien me débarrasser), c’est quand tu utilises un lib qui en dépend :frowning:

ok, je m’arrangerai pour synchroniser lorsque le core « 4.5 » sera sorti du coup

si tu veux bien confirmer ici la liste définitive que tu gardes lorsque tu as fait les vérif nécessaires;
je surveillerai les commit mais, comme d’autres probablement, je risque de rater l’info

Guzzle Elle va virer si vous arrivait à la réintégrer dans vos plugins c’est celle qui me pose le plus soucis lors des monté de version de php

Voila ce que je test actuellement :

{
  "require": {
    "dragonmantank/cron-expression": "^3",
    "symfony/expression-language": "5 - 7",
    "pragmarx/google2fa-qrcode": "^3",
    "bacon/bacon-qr-code": "2 - 3"
  }
}

Pour l’instant en Debian 12 php 8 j’ai pas vu de soucis flagrant et je pense pas pouvoir réduire plus (un jour peut être expression language ou au final je m’en sert que pour des calculs ca se trouve un eval ca fera pareil…)

Mise a jour : il est fort probable que la lib monologue soit supprimée aussi, elle est très bien faite mais pour l’usage qu’on en fait un simple append file marche tout aussi bien et simplifie pas mal le code. A noter que pour le moment le log en syslog ne sera plus possible si la demande est forte je verrais pour developper tout cas mais je doute que ca soit vraiment utile.

Je ne sais pas si c’est lié et je n’ai pas encore eu beaucoup de temps pour chercher, j’ai évidement fait les vérifs de base (update cli, http.error etc) mais rien trouvé pour l’instant

si je vais dans la config jeedom, j’ai cette erreur:
image

juste au cas où tu as eu un truc similaire

(en alpha sur deb12 mis à jour à l’instant donc)

Je reproduis pas sur 7 jeedoms donc je comprends pas trop. La le seul moyen pour trouver est chiant mais j’en vois pas d’autre c’est de supprimer du code petit a petit de la page d’administration jusqu’a trouver le coupable. La c’est clairement une array qui est une string mais pour trouver laquelle (sans meme le pourquoi) je vois pas d’autre solution.

oui, j’étais au même point, je vais chercher

ok j’ai trouvé, voila le message que je reçois suite aux appels http sur https://api.github.com/repos/jeedom/core/...:

{"branchs":{"message":"API rate limit exceeded for x.x.x.x. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https:\/\/docs.github.com\/rest\/overview\/resources-in-the-rest-api#rate-limiting"},"tags":{"message":"API rate limit exceeded for x.x.x.x. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https:\/\/docs.github.com\/rest\/overview\/resources-in-the-rest-api#rate-limiting"}}

x.x.x.x est mon ip

je sais que c’est sensé être une api publique sans besoin d’authentification;
j’ai un ticket ouvert chez eux car j’étais déjà tombé dessus pour un autre projet
ils me disent qu’il n’y a pas de problème, que rien n’est bloqué mais … c’est pas vrai ! et c’est au point mort depuis des mois :frowning:

bref… je suis complètement bloqué avec ce problème chez github mais je vais relancer pour comprendre

pour le core, le minimum serait de valider que le retour est valide et qu’il peut être utilisé pour éviter que ca crash derrière :wink:

Tu peux remettre a jour et retester ?

(j’avais oublie d’envoyer la réponse)

c’est bon, la liste est vide du coup mais ca ne crash pas
pour l’instant c’est suffisant je pense, tant pis si liste vide, ca ne devrait pas arriver en théorie

et en plus juste après mon test l’appel n’était plus bloqué (ca arrive de temps en temps), du coup j’ai de nouveau la liste remplie :sweat_smile:
à voir si ca tient, mais c’est un autre problème

Salut,

On utilise monolog sur plugin-jeemate, je vais regarder comment l’intégrer dans le plugin.

Tu l’utilises comment ? Car normalement jeedom a deja pas mal de possibilités avec la class log

Justement, il faut que je comprenne a quoi il sert et comment il est utilisé. C’est une partie que je n’ai jamais touché donc le code de @Thibaut_T