Bon, intéressantes toutes ces discussions aujourd'hui.
Pour la prod PHP, vu que je commite le fichier .lock de symfony (bonne pratique justement), cela me sert à freezer ma prod, le composer install se servant uniquement du .lock.

mais je vais creuser ce freeze total, c'est tellement pas bête que le cancre informatique que je suis n'y avais point pensé.

GuybrushCela permet de déployer *exactement* les versions pinnées des dépendances, et donc de "cloner" son environnement vers la prod

yaugPour la prod PHP, vu que je commite le fichier .lock de symfony (bonne pratique justement), cela me sert à freezer ma prod, le composer install se servant uniquement du .lock.

Le lockfile permet de "freezer" une version des dép entre plusieurs environnements mais reste un mécanisme de build, soumis à des aléas de build (notamment la fiabilité des repo d'artefacts), il devrait arrêter d'exister à partir de l'étape d'intégration continue.
Le fait qu'on pratique un langage de script ne doit pas nous empêcher de bien séparer les étapes de build et de release. Ça ne nous viendrait pas à l'idée d'utiliser un Cargo.lock pour builder un binaire Rust directement sur le serveur de prod. Je crois que ça devrait être pareil pour PHP

FabeÇa ne nous viendrait pas à l'idée d'utiliser [INSERT CHINESE WORDS HERE]

ah mais je n'ai jamais prétendu utiliser de bonnes pratiques. Je suis un dev propre parmi les devs crades on dira. Mais j'y travaille. Notamment via les suggestions faites ici.

yaugah mais je n'ai jamais prétendu utiliser de bonnes pratiques. Je suis un dev propre parmi les devs crades on dira. Mais j'y travaille. Notamment via les suggestions faites ici.

Ah mais attention c'était pas un jugement sur toi en tant que dev, you are not your code

Et puis il y'en a qui défendent vraiment cette histoire d'installer composer en prod. Je ne peux pas expliquer leurs arguments par contre
Après je serai curieux de savoir si le cas de pip est vraiment très différent ou pas, ça m'a pas sauté aux yeux dans le post de guy.

La situation est un peu similaire avec pip, mais le fait que de nombreux packages soient disponibles sur PyPi (le repository "officiel" de pip) fait qu'on passe nettement plus rarement par git ou svn pour déployer des paquets. Couplé au fait que PyPi interdit d'écraser une release déjà distribuée fait que si tu "pinnes" les dépendances depuis PyPi, tu te retrouveras exactement avec le même code en production qu'en staging. Composer est un peu différent en ce sens, et je pense que la raison est historique : Composer est arrivé avant que Packagist ne soit très répandu, alors que pip est arrivé alors que PyPi était déjà bien ancré dans les usages. C'est pareil avec NodeJS : npm et npmjs (le repository) sont arrivés sensiblement en même temps.

For the record, Packagist.org n'héberge aucun package, il ne repose que sur l'API de Github pour downloader une release.

Il me semble que c'est le cas aussi pour npmjs mais j'ai moins de certitudes.

Ok, je ne savais pas que Packagist se "limitait" à ça et n'hébergeait rien. Pour npmjs, à ma connaissance, ce n'est pas le cas, mais je me trompe peut-être ? Pour PyPI, par contre, je suis sûr que ce n'est pas le cas

Pray for me lexpage community.

Je suis en train de refaire du python (2.7) et je bloque sur des pbs d'encodage. :D

Passe à python 3

En 2.7, le module codecs (de mémoire) est sans doute le plus utile dans la lib standard.

Mais vraiment, passe à python 3, surtout que la branche 2.x est abandonnée à partir de janvier, après 10 ans d'annonces

Oui oui je sais. D'habitude je suis en python 3, mais là je fais avec l'existant pour du script quick (ou pas) and dirty.
Donc je ne vais pas tout de suite me casser les noix à tout enlever pour passer à la 3 sur mon pc et sur le serveur.

Mais clairement, ça va être nécessaire.

Courage