Python : résoudre l'erreur "ImportError: cannot import name main" photo

Python : corriger l’erreur “ImportError: cannot import name main” avec pip

Suite à une mauvaise manipulation, j’ai malencontreusement écrasé la version de pip installée par APT en lançant une commande du type :

pip install pip

ou, selon les cas :

sudo pip install --upgrade pip

Résultat : toute commande lancée avec pip se met à retourner cette erreur :

Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name mainLangage du code : JavaScript (javascript)

Pas glop.

Cette erreur arrive lorsque le script système /usr/bin/pip attend une ancienne interface interne de pip, alors qu’une version plus récente de pip a été installée par-dessus via pip lui-même. En clair, APT et pip se marchent dessus. Et, comme souvent dans ce genre de duel, c’est votre terminal qui prend les coups.

Voici comment réparer proprement pip sous Ubuntu ou Debian, puis éviter de recasser l’installation système.

Lire la suite

Un lapin bleu de dessin animé avec une fourrure blanche, des yeux violets et une cape de super-héros rouge se tient dans un cercle. En dessous, un texte gris en gras indique "VARNISH" avec "CACHE" en lettres plus petites, soulignant comment configurer un cache avec Varnish pour Apache.

Varnish, Apache et PHP : configurer un cache moderne

Installer APC et Varnish devant Apache était une très bonne idée il y a quelques années. À l’époque, APC servait à la fois de cache opcode PHP et de cache utilisateur. Varnish, lui, permettait déjà de placer un reverse proxy HTTP très rapide devant Apache pour servir les pages les plus demandées sans réveiller toute la pile PHP/MySQL.

Aujourd’hui, l’objectif reste valable : réduire la charge, accélérer les réponses et absorber plus de trafic. En revanche, la stack a changé. On ne doit plus installer l’ancien APC. On utilise OPcache pour le bytecode PHP, APCu seulement si l’application en a besoin, et Varnish comme cache HTTP devant Apache lorsque le contexte s’y prête.

Ce guide modernise donc l’approche : diagnostic, OPcache, APCu, Varnish, Apache en backend, vraie IP visiteur, configuration VCL prudente, purge du cache, WordPress, WooCommerce et dépannage.

Lire la suite

Le logo de Cloudflare comporte le mot "CLOUDFLARE" en lettres majuscules noires, à côté d'un nuage et d'un soleil orange avec une flamme blanche au milieu, le tout sur un fond gris clair. On le voit parfois lorsqu'on rencontre une erreur HTTP/2 PROTOCOL_ERROR.

Résoudre l’erreur HTTP/2 stream was not closed cleanly

L’erreur HTTP/2 stream was not closed cleanly apparaît souvent avec curl, Git, une API, un navigateur, un CDN ou un reverse proxy. Elle indique qu’un flux HTTP/2 a été interrompu ou fermé d’une manière que le client considère comme incorrecte.

Le message exact varie selon le contexte :

curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)Langage du code : HTTP (http)
curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)Langage du code : HTTP (http)
error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanlyLangage du code : HTTP (http)

Le réflexe classique consiste à accuser curl, Git ou le navigateur. Pourtant, dans beaucoup de cas, le problème vient plutôt du serveur, du CDN, d’un proxy intermédiaire, d’un en-tête HTTP invalide, d’un timeout, ou d’un backend qui coupe la réponse trop tôt.

Voici une méthode propre pour diagnostiquer et corriger l’erreur, sans désactiver HTTP/2 au hasard comme on débranche une multiprise en pleine prod.

Lire la suite