laurentb a écrit 274 commentaires

C'est quoi cette réponse ? Qu'est-ce que j'en ai à faire de la fréquentation des sites que j'utilise ?

Pareil, je serais très intéressé. Que GitHub ou Gitorious soit libre, je m'en fiche, ce n'est pas ce qui me gène. En plus, j'ai l'impression que ça formate à utiliser un seul process, alors qu'il y a un grand nombre de façons d'utiliser Git. La plupart de mes contributions à des projets qui sont sur GitHub seraient plus simples à soumettre via des patchs, mais ce n'est pas supporté, et on ne peut même pas attacher des fichiers aux tickets !

Et rien que par la façon de créer des repository sur Baregit (par git, plutôt que par le web), je suis conquis. Manque plus qu'à être plus rapide et fiable que GitHub (pas dur) et ça sera plutôt bien parti !

Ça ne change rien au fait que tu as tort de l'utiliser dans ta croisade contre on ne sait trop quoi.

Ben, oui. C'est bien ce que je dis. Je n'ai jamais parlé du fait que ce n'était pas libre.
Tu as l'air d'un sacré boulet en fait :/

Oui, je peux. Encore faut-il que le développeur accepte ce fonctionnement ; la plupart n'ont ni mailing-list ou même un mail disponible.

Ce n'est malheureusement pas mon expérience des projets développés sur GitHub. Il y en a même qui font le merge depuis l'interface web.

Il faut utiliser l'interface des "pull request", qui est tout sauf ergonomique et impose son interface.

Oui, il y a beaucoup de gens stupides dans le monde, qu'est-ce que ça prouve de plus ? Ça ne rend pas le service de GitHub moins exécrable.

Linus a utilisé GitHub uniquement pour stocker son dépôt, c'est donc particulièrement prétentieux de l'associer à cette liste de priorités.

https://github.com/torvalds/linux/pull/11#issuecomment-2023618

Et les autres "pull request" sont pires.

Pour utiliser Github (uniquement pour stocker du git, pas la gestion de projet qui elle enferme complètement, alors que l'on peut partir avec son dépot quand on veut), j'ai pu constater qu'il n'est ni sécurisé, ni très disponible. Rien que la lenteur des push par rapport à mon petit serveur me donne envie de les quitter. Et il faut être complètement fou pour y mettre son code privé (sans compter les prix absurdes).

Le Crédit Agricole a un site similaire mais quand même un peu différent pour chaque région (weboob en gère pas mal, on sait pas exactement combien). Donc ça ne serait pas étonnant.

En fait ça vient de quand XDG_DATA_HOME est défini, on supposait qu'il ne contenait pas la partie « share ». Ça va être corrigé sur la version git.

Ah, je pense avoir deviné d'où ça vient.
Est-ce que tu as les variables d'environnement $XDG_DATA_HOME et $XDG_CONFIG_HOME de définies ?

Les modules ne sont justement pas de la configuration, et sont donc dans .local, conformément à la spécification XDG.

Il y a un conflit d'intérêt évident entre les concepteurs des sites et les programmeurs de scripts.

C'est vrai, mais ce n'est pas une fatalité. Je serai prêt à payer un abonnement modique pour avoir accès à une bonne API. Cela devrait compenser par exemple les pertes de revenus liés à la publicité. De plus, fournir une information par une API coûte largement moins cher que de fournir un site complet.
Et je serai prêt à payer encore plus pour un module weboob maintenu par le site en question (et si les choses sont bien faites, le site pourrait ajouter un cache local permettant de diminuer le « coût » de weboob).

Le HTML a une caractéristique particulière, c'est qu'il impose un modèle "open source"

Je vois ce que tu veux dire. On a pu rencontrer du HTML bien pourri (notamment les sites de banques où il faut y aller de manière quasiment heuristique) et arriver à en faire quelque chose. Cependant le code JavaScript, surtout minifié, est une autre paire de manches.

la liberté de faire évoluer son site est fondamentale, on ne peut pas être prisonnier de ses visiteurs

Je n'ai rien contre leur liberté, mais je trouve justement étrange le peu d'attachement à la stabilité et la rétrocompatibilité des sites internet, alors que c'est beaucoup plus répandu dans le logiciel « lourd ». C'est d'ailleurs ce qui a poussé la création du système de mise à jour des modules dans Weboob. On est attachés à la stabilité des applications et de l'API (du moins dans une même version majeure), mais pour les modules on est obligés de s'aligner sur les sites.

C'est par impossibilité légale de reprendre le logo je suppose?

Oui. Le logo original n'est de toute façon souvent pas libre, donc difficile de l'inclure dans les sources. Et quitte à refaire le logo, autant s'amuser un peu (et le côté parodique permet de profiter d'une exception au droit d'auteur je suppose).

Cela changera peut-être dans le futur, puisque les modules sont maintenant capables de récupérer le « favicon », tout en nous évitant de le distribuer.

Oui je pense que si le terminal n'est pas en UTF-8, il va y avoir des problèmes (et comme la plupart des sites ont de l'unicode, c'est à peu près obligatoire).
Même depuis Windows tu devrais pouvoir configurer le client SSH du Windows et les locales du Linux pour utiliser UTF-8.

Mais tous les rapports de bug détaillés sont les bienvenus.

Moi j'en ai 30, dont 15 dédiés à la paranoïa/sécurité. Ça compte ? :)

Je pense que tu as raison (y compris sur les guillemets). On manque actuellement de relecteurs. Ça me ferait même plaisir qu'on trouve des failles dans mon code un jour :)

Cependant, Weboob est potentiellement vulnérable d'« homme au milieu » et de « développeur malveillant », alors que les navigateurs sont quand même beaucoup plus complexes et sensibles. En tout cas moi je n'ai pas confiance en mon navigateur !

Elles sont spécifiées dans les packages. Pas dans le setup.py, pour une raison qui n'est peut-être plus valable (surtout pour les plus essentielles comme yaml, mechanize ou lxml).

En revanche certains modules peuvent avoir des dépendances supplémentaires, à installer par l'utilisateur de la façon qu'il souhaite (idéalement par un paquet de sa distribution).

Il y a un effort particulier pour ne pas tout planter et afficher un message à l'utilisateur quand une dépendance manque.

Mais je suis d'accord, il y a encore du travail au niveau de la documentation de l'installation par les sources, et pour avoir plus de paquets de qualité pour les diverses distributions.

Ah ! Ça me motive encore plus à essayer de faire un nouveau « Browser » basé sur cette librairie que j'avais déjà remarquée pour d'autres raisons.

Car urllib/urllib2/mechanize sont assez lourds à utiliser et pas toujours très adaptés au debug.

Je pense que l'on a bien conscience de ces divers problématiques. C'est d'ailleurs rassurant de voir que d'autres personnes s'en soucient.

Les développeurs vérifient le code et les mainteneurs des modules bancaires ne sont pas anonymes ce qui diminue fortement l'incitation à ce genre de pratiques.
Tu peux donc vérifier le code (assez accessible) ou faire confiance aux développeurs principaux.
Rien ne garantit qu'il n'y a pas de code « caché ». Mais c'est aussi le cas de ton OS ou de ton navigateur (et de toutes ses extensions !).

Pour le téléchargement des modules, on utilise GPG pour vérifier qu'ils sont authentiques (je me suis basé sur la façon de faire de Debian). Il n'y a pas de mise à jour silencieuse, l'utilisateur est toujours au courant. Mais pas de notification de failles de sécurité, ce qui pourrait effectivement être utile dans le futur.
Je pense qu'on utilisera bientôt le support GPG de git aussi, qui est disponible depuis peu.

Au sujet des relations entre développeurs, je n'ai pas en tête les proportions, mais la plupart se sont déjà rencontrés et ne sont pas employés par la mafia (boobank) ou la RIAA (weboorents).

En revanche, il reste les problèmes évoqués dans d'autres commentaires :

• pas de vérification des certificats SSL
• stockage des mots de passe

Pour ma part je stocke les mots de passe sur une partition chiffrée ; on peut aussi choisir de ne pas les enregistrer. On projette d'utiliser les keyrings sécurisés fournis par le système plutôt que d'inventer notre solution.

J'ai des comptes dans deux banques différentes et aucune ne me propose ça. Il y a une liste de banques qui le font quelque part ?

De plus, c'est là aussi quelque chose qui intéresse weboob, car je suppose qu'il faut quand même se connecter avec son navigateur (et personnellement je trouve ça très irritant de cliquer sur le pavé numérique) : il pourrait automatiser la récupération du fichier (d'ailleurs, si tu as envie de développer cette fonctionnalité tu es le bienvenu). Et pour les banques qui ne proposent pas le fichier, il pourrait en écrire un à partir des infos du site !

Pour ma part j'utilise déjà munin donc le script m'intéresse pas mal.

Quant aux services en ligne c'est juste complètement contraire à l'idée de weboob : ne plus utiliser son navigateur !

L'idée de weboob est justement d'être un outil cohérent pour gérer une multitude de sites, plutôt qu'un tas de scripts isolés qui réinventent la roue et qui ne sont pas maintenus.

Ce qu'apporte weboob c'est des outils pour développer une architecture avec backend (interaction avec le site) rapidement, et des applications découplées.

De plus, certaines applications ont des tests unitaires lancés régulièrement, ce qui leur permet d'être toujours à jour par rapport aux modifications des sites. Difficile de faire ça sans une architecture à la weboob.

C'est ça d'être un trader ;-). J'ai en effet constaté que certains comptes étaient mal reconnus, c'est maintenant corrigé dans le git. Si ce n'est toujours pas le cas pour toi, n'hésites pas à rapporter le bug !