flan a écrit 1848 commentaires

En prenant un cas caricatural et en oubliant tous les autres avantages (lib standard, écosystème, absence de compilation, …), ça ne change pas grand-chose, forcément.

Merci pour ton retour. J'ai un peu l'impression que tu en parles au passé, a-t-il été abandonné, ou est-ce bien un changement de poste de ta part ?

Au final, avec Kerberos, cela fonctionnait-il bien ? Comment était possible la transmission du ticket Kerberos au smtp derrière SoGO ? Pas d'authent' en local sur le port 25 ?

Tu as trois possibilités pour les paquets Python :

• avec le système de packaging de ta distrib (apt-get install python-numpy)
• depuis le dépôt avec les sources et la recompilation qui va avec
• depuis le dépôt avec des versions précompilées (avec plusieurs choix d'archi)

par exemple : https://pypi.python.org/pypi/numpy/1.9.3

Et ces langages font souvent appel à du C pour les fonctions consommatrices de ressources. Après, je suis très content d'utiliser ces langages, il ne faut juste pas se voiler la face.

D'ailleurs, on peut faire du calcul matriciel en Python qui soit aussi performant que le code C équivalent. Ça n'a absolument rien de magique, car les bibliothèques bien écrites (comme numpy) sont codées en C, et le code Python (qui est la seule chose que le développeur voit, et qui sera facile à écrire et concis) ne sert que de ciment au code qui calcul. Du coup, on se moque que le code Python ne soit pas très performant, vu qu'on n'y passe qu'un pouillème du temps de calcul.

Ok, merci encore pour toutes ces réponses.

pour les catégories ou les flux publics, je pensais à la possibilité de mettre des flux ou des groupes de flux visibles d'autres personnes, avec une page proposant ces groupes déjà prêts à être ajoutés dans une sélection perso.

Merci pour tes réponses. Je n'ai pas encore eu le temps de m'y plonger sérieusement, mais je note pour plus tard, dans ma liste de choses à installer ^ ^

Peut-on l'utiliser en reverse proxy, plus simplement ?

Y a-t-il moyen de compiler facilement et de l'exporter sous forme de .deb ?
De plus, si je comprends bien, la conf' est écrite dans un fichier .py au milieu du code. Serait-il envisageable de l'exporter dans un .ini ?

Que se passe-t-il pour la mise à jour de la base de données si tu changes le modèle ? Je suis habitué au système de migrations de Django, mais je ne connais pas du tout Flask.

Encore une question : peut-on partager ou rendre publiques des catégories ? Je n'ai pas vu de telle option en me logguant rapidement.

Je suis également franchement intéressé. Ça me paraît pas mal du tout ! Je n'ai pas eu le temps de tester, mais je le mets sur ma liste de choses à installer.

Par pur plaisir d'être pénible, j'aurais quelques remarques, uniquement basées sur la doc et liées à mes petites manies :

• pour moi, un projet Python devrait s'installer via pip (quitte à avoir une commande pour créer la doc), ou via des paquets (type .deb ou .rpm), le tout associé à un fichier de conf' : c'est toujours plus agréable d'avoir une seule méthode pour installer tous les projets, et de pouvoir les installer sans accès internet. C'est en tout cas ainsi que je raisonne pour mes projets perso (basés sur Django), mais j'ai l'impression que ce n'est pas le cas ici.
• y a-t-il moyen d'utiliser le REMOTE_USER (ou HTTP_REMOTE_USER) pour authentifier l'utilisateur ? j'aime bien avoir mes utilisateurs authentifiés via Kerberos.

C'est un bête Mac Mini. Quant à la consommation, je ne l'ai pas fait directement, mais d'autres que moi l'ont mesurée.

J'espère qu'un portable fait largement moins de 20 W au repos, vu que mon ordi fixe fait dans les 10 W, avec un Intel Core 2 Duo + 8Go de RAM et un SSD (et il fonctionne 24H/24 depuis 2009).

tu as raison, j'aurais pu préciser que Darwin en soi n'avait strictement aucun intérêt :)

OS X n'est pas une distrib BSD, ce n'est d'ailleurs même pas un noyau BSD. Autour du noyau XNU/Mach se trouvent pas mal d'outils d'origine BSD (la gestion des drivers, au moins au début vu que je ne sais pas si c'est toujours le cas), mais le noyau n'est pas le même.

En (très) gros, tu as l'empilement
OS X = (Cocoa|Quartz|..) + Darwin
Darwin = outils maison + outils BSD + XNU/Mach
Darwin est complètement open-source et est un OS complet que tu peux installer (mais sans interface graphique intéressante)

Pour avoir assisté à quelques congrès d'info (parfois très théorique, parfois très appliquée), j'ai vu beaucoup de Mac (voire une écrasante majorité) et beaucoup d'écrans affichaient un terminal sous une forme quelconque.
De mon côté, si je n'avais pas de terminal, l'option "Mac" ne serait même pas envisageable.

Plutôt GNU/Windows, non ?

Oui, c'est sûr que find est vraiment l'argument clef qui va faire basculer les gens d'OS X à Windows :)

(sinon, je ne m'étais jamais rendu compte qu'installer une autre version de Python était plus compliquée que de télécharger le .dmg et de cliquer quelques fois sur OK).

Logiquement tu ne t'intéresse qu'à tes dépendances direct et si tu utilise ces dépendances c'est que tu pense qu'elles sont assez malines pour faire de même. C'est l'unique façon de faire si tu ne veux pas forker tes dépendances pour jouer à mettre à jour une dépendance de ta dépendance directe.

Il faut donc analyser la qualité de chaque dépendance. Ça prend du temps, surtout quand on voit les absurdités montrées plus haut (franchement, qui penserait que vérifier qu'un objet est un entier positif demande 3 dépendances ?!?). Faire ce travail pour quelques projets ne me pose pas de problème particulier, le faire pour plusieurs centaines m'en pose beaucoup plus.

A moins que tu utilises d'une manière que je ne connais pas bien, tu ne gère jamais toutes ces dépendances. Tu vas par exemple avoir une dépendance à babel qui lui utilise d'autres dépendances. Chacun s'occupant de ses dépendances. Jamais tu n'as à gérer l'ensemble de ton graph de dépendance.

Oui, c'est la théorie. Ça implique de faire confiance à toutes tes dépendances. On peut trouver du bon et du moins bon dans tous les langages ; mais encore une fois plus tu as de dépendances différentes, plus tu as de chances de retrouver avec une dépendance foireuse dont une sous-dépendance te posera problème.
C'est beaucoup plus facile de faire confiance à 3-4 personnes qu'à 300 ou 400. À nouveau, le problème n'est pas qualitatif mais quantitatif.

C'est une question d'usage aussi, quand je fais du JS j'ai peu de dépendances, comme lorsque je fais du ruby.

Oui, nous sommes d'accord. Tu peux faire du mauvais ou du bon code avec n'importe quel langage. En théorie, du moins. En pratique, la qualité moyenne (je ne parle pas de toi spécifiquement !) varie fortement d'un langage à l'autre.

Oui, mais via un outil maison pour appliquer stdeb sur toutes les dépendances avec d'éventuels patches.

C'est pas sérieux comme argument. Sinon tu pousses le raisonnement et tu n'utilise aucune bibliothèque ou framework, aucune dépendance d'aucune sorte puisque tu ne maitrise pas la qualité de tes dépendances à moins d'aller toutes les auditer.

Tu ne peux pas pousser à fond cet argument sans le vider de sa substance. Le problème n'est d'avoir des dépendances et un graphe de dépendance quelconque. Le problème est d'avoir beaucoup de dépendances et un graphe de dépendance compliqué.
Si tu as dix dépendances qui n'ont quasiment pas de dépendance, il est humainement possible de s'en occuper.

Si tu as cent dépendances qui ont chacune un graphe de dépendance complexe (tu augmentes fortement la probabilité qu'il y ait un problème dans une dépendance de dépendance de dépendance, dans un code que tu ne maîtrises absolument pas), ce n'est plus humainement possible de s'en occuper.

Ce n'est pas un problème de qualité, c'est un problème de quantité. Et en pratique, ce problème arrive avec JS, pas avec Python.

Si, en t'accrochant bien, tu peux sûrement faire un projet avec des centaines de dépendances directes faites par autant de développeurs et sans aucune communauté derrière. Par contre :
* chaque dépendance ne sera présente qu'une seule fois (impossible de charger dans le même programme plusieurs versions de la même lib).

* ton graphe de dépendance ressemblera sûrement à une étoile et sera moins joli : tu n'auras pas à trouver que X dépend de Y qui dépend de Z qui dépend de T qui dépend de U qui dépend de V qui vient d'amener une incompatibilité.

Théoriquement, pypi pourrait très bien être pollué de dizaines de milliers de packages de deux lignes.
En pratique, la qualité moyenne des packages Python actuels (je ne parle pas des paquets Python 2.1 qui n'ont pas été mis à jour depuis 15 ans) est franchement pas mal. La majorité des paquets que j'utilise ont très peu de dépendances (quand ils en ont) sont publiés sur pypi, respectent tous la même norme de code (PEP008), ont une doc propre mise à jour automatiquement sur readthedocs, des tests lancés sur travis.ci, sont hébergés sur Github avec la possibilité de remonter des bugs. Encore mieux, je peux la plupart du temps créer des paquets .deb ou .rpm propres sans rien toucher.

Et d'un côté il a raison : même si le module est là pour éviter une oneliner avec 2 conditions ça reste intéressant, pas envie de se souvenir justement de comment ça s'écrit.

Je ne suis pas du tout d'accord. On se retrouve immédiatement avec des graphes de dépendances énormes et le moindre projet n'est plus du tout maintenable : quand tu as une dizaine de dépendances, tu peux te tenir au courant de leur activité, prévoir les mises-à-jour (par exemple, je sais que Django passe en 1.10 en août et j'ai déjà prévu les modifications pour être compatible), tu connais leur licence, tu peux avoir un ensemble à peu près cohérent, tu limites les doublons de code.

Avec le JS, le moindre projet va dépendre de centaines de développeurs indépendants qui mettent leur code à jour chacun de son côté, avec des licences potentiellement exotiques, qui peuvent ajouter des bugs et affecter en cascades d'autres dépendances intermédiaires, etc.
Comment peux-tu avoir la moindre garantie de qualité si tu ne maîtrises absolument rien au niveau des dépendances ?

Il suffit de prendre le code "compilé" (le bytecode généré à la première exécution) :)

On pourrait croire que left-pad est un exemple qui sort de l'ordinaire… mais en JS, non, malheureusement.

http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to-program/

There’s a package called isArray that has 880,000 downloads a day, and 18 million downloads in February of 2016. It has 72 dependent NPM packages. Here’s it’s entire 1 line of code:

return toString.call(arr) == '[object Array]';

There’s a package called is-positive-integer (GitHub) that is 4 lines long and as of yesterday required 3 dependencies to use. The author has since refactored it to require 0 dependencies, but I have to wonder why it wasn’t that way in the first place.
A fresh install of the Babel package includes 41,000 files
A blank jspm/npm-based app template now starts with 28,000+ files

Mais comment une lib qui fait quelque chose d'aussi compliqué que vérifier qu'un objet est un entier positif ou nul peut-elle avoir 3 dépendances ? C'est simple :

var passAll = require('101/pass-all')
var isPositive = require('is-positive')
var isInteger = require('is-integer')
module.exports = passAll(isPositive, isInteger)

Avec Debian, tu peux fournir un paquet différent mais qui remplit exactement le même rôle.

Par exemple, tu peux avoir "JVM" en dépendance, et cette dépendance peut aussi bien être fournie par la JVM d'Oracle qu'OpenJDK (oui, je sais, c'est plus ou moins la même chose maintenant) ou toute autre JVM.

Pour reprendre ton exemple : les éléments clipsés reviennent moins chers que des éléments vissés.
Faire du « jetable » coûte la plupart du temps nettement moins cher. De la même façon, s'ils garantissent un objet pour deux ans, ils vont le faire juste assez solide pour qu'il tienne deux ans et ne mettront pas un centime de plus pour qu'il tienne plus longtemps. Après, rien n'empêche le gouvernement d'augmenter les garanties légales minimales.

Mine de rien, les clients décident très largement du marché. S'ils continuaient à acheter des choses qui durent et réparables, je suis persuadé que les constructeurs ne fabriqueraient que du solide réparable.

De plus, certaines machines disposent déjà de lest amovible, ce qui est largement suffisant (et peut-être encore plus pratique que de l'eau à remplir).