Dites 0.i à Weboob

Posté par  . Édité par bubar🦥, ZeroHeure, Benoît Sibaud et Nils Ratusznik. Modéré par Florent Zara. Licence CC By‑SA.
Étiquettes :
42
22
mai
2014
Internet

Weboob (Web Outside Of Browsers) est un ensemble d'applications interagissant avec des sites web.

Et pour profiter du printemps, voici une nouvelle version de Weboob ! Weboob 0.i a en effet été acceptée sur le Web lundi dernier.

Cette version bat de nouveaux records de changements, avec 628 commits provenant de 19 contributeurs. Elle apporte la révolution du projet Browser2 (nouveau navigateur pour simplifier l'extraction des données), ainsi que de nombreux nouveaux modules.

Les nouveautés sont détaillées en seconde partie de la dépêche. Weboob compte désormais 161 modules, gérant au total encore plus de sites (certains modules pouvant concerner plusieurs sites Web).

Sommaire

Browser2 : un nouveau navigateur

Puisque le but est d'extraire des données sur le Web, le navigateur est une composante essentielle du projet. Il permet de simplifier les requêtes HTTP, de gérer les sessions, les cookies, de remplir les formulaires, etc.

Le premier navigateur développé (toujours en service) est basé sur la bibliothèque mechanize, avec toute une couche d'abstraction rajoutée par Weboob pour en simplifier l'utilisation. Nous étions cependant limités par cette bibliothèque : la gestion des formulaires est affreuse, le SSL ne vérifie pas les certificats, le debug des entêtes HTTP était compliqué, etc.

Un projet de nouveau navigateur était donc lancé depuis un certain temps, en se basant cette fois sur la bibliothèque python-requests. Le projet a été retardé plusieurs fois, notamment du fait des nombreux changements d'API de la bibliothèque, empêchant de développer quelque chose de stable. Cette période de maturation de la bibliothèque semble terminée, et le travail a donc pu reprendre.

Cette bibliothèque tenant toutes ses promesses, le nouveau navigateur (Browser2) de Weboob est bien plus performant que le précédent. Nous avons pu partir de bases solides pour reconstruire un navigateur. Les formulaires sont ainsi très simples à remplir, les URL sont bien mieux gérées, les entêtes HTTP (envoyées et reçues) sont sauvegardées en mode Debug, et la gestion de la pagination est enfantine. Enfin, le SSL est pleinement fonctionnel.

ListItem : factorisons le code

Ce n'est pas lié au changement de bibliothèque, mais cela vient également avec le projet Browser2. En examinant nos expériences de plusieurs années sur le parsing de pages, et le code des modules, il était évident pour nous que ce dernier était très (trop) répétitif. Nous voulions limiter la duplication du code, et simplifier l'écriture de module.

C'est cette réflexion qui a conduit à l'écriture des classes ListElement et ItemElement, permettant d'obtenir un code très déclaratif. L'extraction des données se base sur des filtres, dont la composition permet de presque tout faire. Les modules ont la possibilité de déclarer des filtres personnalisés, mais l'objectif est bien de les centraliser dans le cœur pour les réutiliser au maximum.

Il nous reste encore des choses que nous voulons améliorer pour le projet Browser2, mais nous le pensons déjà pleinement utilisable et 24 modules sont maintenant basés dessus. Nous sommes très satisfaits du résultat, notamment quand on observe que la conversion d'un module permet très souvent de diviser le nombre de lignes de code par deux. La documentation est prête, et nous sommes preneurs de tout retour concernant ce navigateur.

Pour plus d'informations sur ce sujet, le Planet du projet contient de nombreux articles détaillés.

Des mots de passe protégés

La protection des mots de passe était souvent un sujet de discussion à l'intérieur et autour du projet. En effet, il n'existait que deux alternatives : stocker le mot de passe dans un fichier en clair, ou bien laisser le champ vide et taper le mot de passe à chaque utilisation.

Plutôt que de réinventer la roue avec un gestionnaire de mot de passe propre au projet, il est désormais possible de configurer un appel à une application externe pour obtenir les identifiants d'un compte. La syntaxe rappelle celle d'un script bash, avec l'utilisation des symboles ` pour délimiter la commande.

Un exemple d'utilisation est ainsi de remplacer dans le fichier de configuration backends une ligne :

password = 123456

par :

password = `pass banques/ing`

Les utilisateurs peuvent également utiliser l'outil de configuration weboob-config pour mettre à jour ce champ, et les nouveaux utilisateurs auront l'option d'utiliser cette méthode dès la configuration d'un module.

Les reprises de Weboob

Si Weboob fournit de (nombreuses) applications, elles n'ont pas vocation à remplacer les applications spécialisées (et bien plus efficaces) existantes. Dans l'idéal, les applications Weboob ne seraient utilisées que pour exporter vers un format standard, et les données traitées par des applications existantes.

C'est pourquoi nous sommes toujours heureux de voir des projets intégrant des appels directs à Weboob. C'est courant dans le monde des applications bancaires (Budgea pour du propriétaire, CozyCloud et son gestionnaire financier, skrooge pour importer les données bancaires ainsi que les factures, etc), mais moins pour les autres applications.

Nous profitons donc de cette dépêche pour parler d'un plugin pour la recherche de vidéos pour Grilo, et d'un plugin pour la recherche dans Gnome Shell. Plus d'informations sur le blog de l'auteur, avec notamment des vidéos de démonstrations.

Les petites nouvelles

Dans les petites nouvelles, la conversion de Weboob vers Python 3 a commencé. Nous prévoyons de rendre progressivement compatible le cœur, les applications, et les modules basés sur Browser2.

Chaque version de Weboob s'accompagne toujours de nouveaux modules, celle-ci n'est pas en reste avec de nombreux modules permettant d'envoyer/recevoir des images. Un module pour le site La Centrale fait également son apparition, ainsi que pour le site de rencontre de plus en plus populaire Tinder. Cela pourrait sauver une génération.

Enfin, on entend parfois sur ce site que le nom du projet est incompatible avec une utilisation professionnelle. La réalité prouve le contraire, avec une prochaine utilisation de Weboob par la Banque Accord (via l'entreprise Budget Insight). On peut même trouver des offres d'emploi mentionnant Weboob.

Association

L'association Weboob continue son rôle de pilotage et protection du projet. Elle tiendra son assemblée générale le 12 Juin dans un lieu qui reste à définir. Si vous êtes intéressés, une annonce est à venir sur la liste de diffusion du projet, et le bas de la page de l'association sera mis à jour.

Contributeurs

Merci aux contributeurs qui ont participé à cette version :

  • Adrien Kunysz ;
  • Ahmed Boussadia ;
  • Benjamin Carton ;
  • Florent Fourcot ;
  • François Revol ;
  • Gabriel Kerneis ;
  • Johann Broudin ;
  • Laurent Bachelier ;
  • Matthieu Rakotojaona ;
  • Noé Rubinstein ;
  • Pierre Mazière ;
  • Raphaël Rigo ;
  • Roger Philibert ;
  • Romain Bignon ;
  • Vincent Osele ;
  • Vincent A. ;
  • Vincent Paredes ;
  • Vincent Texier ;
  • Yann Rouillard.

Weboob est un projet qui vit grâce à ses contributeurs. Si vous souhaitez l’améliorer et que vous connaissez le Python, n’hésitez pas à contribuer.

Aller plus loin

  • # Python 2 + Browser

    Posté par  (site web personnel, Mastodon) . Évalué à 7.

    Bravo pour cette version, c'est un projet actif et c'est impressionnant de voir le nombre de modules.

    2 petites questions:

    • est-ce que vous allez maintenir une version python 2 (éventuellement sous la forme d'un code utilisable sous python 2 et 3) ? Dans le cas contraire, quand estimez vous la fin du support python 2 ?

    • est-ce que browser2 est utilisable en dehors de weboob ? Pour un projet d'une fois qui ne mérite pas une inclusion sous forme de module ?

    • [^] # Re: Python 2 + Browser

      Posté par  . Évalué à 6.

      est-ce que vous allez maintenir une version python 2 (éventuellement sous la forme d'un code utilisable sous python 2 et 3) ?

      C'est actuellement ce qui est fait, notamment en utilisant des __future__. C'est pas très beau, mais nous resterons ainsi pendant très longtemps. Je ne vois pas une fin de la gestion de python 2.7 avant plusieurs années.

      est-ce que browser2 est utilisable en dehors de weboob ? Pour un projet d'une fois qui ne mérite pas une inclusion sous forme de module ?

      Oui bien entendu, il suffit d'importer weboob.tools.browser2. Et il est également possible de faire son propre dépôt pour des modules personnels.

    • [^] # Re: Python 2 + Browser

      Posté par  (site web personnel) . Évalué à 4.

      est-ce que browser2 est utilisable en dehors de weboob ? Pour un projet d'une fois qui ne mérite pas une inclusion sous forme de module ?

      Justement, je suis actuellement en train d'écrire du code qui utilise uniquement Browser2. Ça marche sans problème.

      Je pense cependant que Browser2 va encore pas mal évoluer, donc il faut suivre le développement.

  • # Je suis un peu étonné

    Posté par  . Évalué à -4.

    Web Outside Of Browsers utilise un Browser !?

    Ca fait bizarre non ?

    Je suis de très loin ce projet (en gros, je lis les dépêches sur LinuxFr et puis voilà) mais je trouve que ca fait contradictoire avec le nom.

    Finalement, on pourrait imaginer un addon Firefox qui implémenterait tout cela.
    Pour le nom de l'addon, je propose:

    Weboobbib: Web Outside Of Browsers Back In Broswer.

    Sinon, bravo quand même pour le projet!

    • [^] # Re: Je suis un peu étonné

      Posté par  (site web personnel) . Évalué à 6.

      Un browser oui, mais uniquement programmable, alors que un navigateur comme Firefox est interactif.

      L'utilisateur, avec weboob, ne "browse" pas.

    • [^] # Re: Je suis un peu étonné

      Posté par  . Évalué à 5.

      Ce qui pourrait être sympa c'est un WebOOBBiT (Web Out Of Browser But In Terminal) pour permettre d'utiliser browser2 dans des scripts shell.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Je suis un peu étonné

        Posté par  . Évalué à 4.

        Tu as la classe WebNip qui te permet d'utiliser Weboob comme une bibliothèque Python.

      • [^] # Re: Je suis un peu étonné

        Posté par  . Évalué à 4.

        Il y a déjà phantomjs pour ça.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Je suis un peu étonné

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          Et SlimerJS

          L'avantage de PhantomJS et Slimerjs, c'est que ce sont des "vrais" navigateur, en ce sens où la page "vit" comme dans un navigateur classique, avec le JS exécuté etc… Avec Browser2, il me semble que cela ne soit pas le cas, et donc ne permet pas d'aller sur tous les sites (qui utilisent intensivement le JS) à priori (en tout cas pas sans avoir faire une inspection profonde de la page pour voir toutes les requêtes ajax de contrôles faites, afin de les reproduire etc…)

          • [^] # Re: Je suis un peu étonné

            Posté par  . Évalué à 3.

            je crois que la non execution du JavaScript dans weboob est un choix volontaire: tout le JS nécessaire à l'obtention des données, et seulement celui là, est réimplémenté dans le module du site

            • [^] # Re: Je suis un peu étonné

              Posté par  (site web personnel) . Évalué à 2.

              Globalement on simule le navigateur, ce qui a des avantages (moins de requêtes et moins de ressources) et des désavantages (certains sites sont plus durs à gérer).

          • [^] # Re: Je suis un peu étonné

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            Je crois que tu bosses sur SlimerJS justement non ? Est-ce qu'il y a des facilités pour l'utiliser en Python ? Il n'est pas encore headless apparemment, la FAQ indique comment se passer de xorg, mais quid des dépendances ? Elles sont nombreuses ?

            En fait je vais avoir besoin d'un projet du style pour les tests automatisés de mon projet, et pour le moment PhantomJS me parait plus intéressant notamment parce qu'il est headless (et qu'on trouve facilement comment l'utiliser avec Python).

            • [^] # Re: Je suis un peu étonné

              Posté par  . Évalué à 4.

              Si c'est pour des tests automatisés, je conseillerais Casperjs avec les backend phantomjs et slimerjs pour maximiser la surface de test. Par contre, c'est du JavaScript.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Je suis un peu étonné

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              Je crois que tu bosses sur SlimerJS justement non ?

              oui :-)

              Est-ce qu'il y a des facilités pour l'utiliser en Python ?

              On pourrait, en compilant XulRunner avec le support python (utilisé par exemple par l'IDE Komodo). Et réimplementé pas mal de truc en python. Faisable mais ça demande du boulot.

              Il n'est pas encore headless apparemment, la FAQ indique comment se passer de xorg, mais quid des dépendances ?

              Pas la dépendance, ce sont les dépendances classiques de Firefox/XulRunner, et celle de xvfb… Ça fonctionne out of the box sur une ubuntu par exemple, après avoir installé Firefox et xvfb.

              et qu'on trouve facilement comment l'utiliser avec Python

              on trouvait. la version python de PhantomJS n'est plus maintenu depuis longtemps à priori…

              • [^] # Re: Je suis un peu étonné

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                on trouvait. la version python de PhantomJS n'est plus maintenu depuis longtemps à priori…

                une des réponses (la mieux notée) passe par selenium. Je n'ai pas testé mais gageons que ça reste d'actualité.

                bon de toute façon dans l'idéal nos tests vont devoir passer su Gecko et Webkit, donc si l'API est compatible (ce qui à peu près le cas mais pas à 100% de ce que j'ai lu), je vais faire en sorte de pouvoir utiliser phantomJS et SlimerJS.

                en tout cas merci, c'est bien utile ce genre de projet.

            • [^] # Re: Je suis un peu étonné

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              pour le moment PhantomJS me parait plus intéressant notamment parce qu'il est headless

              Oui mais il a un super vieux moteur webkit. Et la version 2, qui devrait utiliser un webkit récent, se fait attendre depuis longtemps…

      • [^] # Re: Je suis un peu étonné

        Posté par  (site web personnel) . Évalué à 3.

        La plupart des applications Weboob sont faciles à scripter, et on peut personnaliser la sortie.

        Et enfin, il y a la console Python !
        Soit import de Browser2, soit weboob-debug MODULE pour faire directement des appels sur le module ou son browser.

        • [^] # Re: Je suis un peu étonné

          Posté par  . Évalué à 3.

          La plupart des applications Weboob sont faciles à scripter

          Oui et non. Ça semble facile à scripter, mais si on veut être un peu rigoureux, alors c'est plus difficile. Par exemple, j'ai été confronté à ces problèmes : remontée correcte des erreurs, être sûr qu'il n'y aura rien d'interactif (MAJ des modules en cas d'erreur), éviter qu'un module soit désactivé parce qu'il n'a pas marché le coup précédent, être blindé sur la sortie (ne pas avoir peur de choses non prévues : caractères, nouvelles infos, etc.) [j'utilise le format 'multiline' en définitive], …
          Ce que j'ai écrit, c'est un script autour de boobank lancé par crontab toutes les nuits qui me prévient quand des événements surviennent sur mes comptes bancaires (solde inférieur ou supérieur à une limite, modification du solde, …) Ma banque proposait un service payant bien moins performant (alerte quand le solde passe en négatif, donc trop tard)

          • [^] # Re: Je suis un peu étonné

            Posté par  . Évalué à 4.

            Ça peut donc valoir le coup que tu remontes précisément les problèmes que tu as rencontrés, pour que l'on corrige upstream.

            • [^] # Re: Je suis un peu étonné

              Posté par  . Évalué à 2.

              Sous quel forme préférez-vous les retours ? En général, en en parlant dans ce genre de dépêche (je crois que je l'avais déjà fait pour d'autres points lors d'une précédente dépêche), j'ai un bon retour de la part des développeurs ;-)
              Par contre, mon expérience avec le système de bug de weboob n'est pas très bonne (aucun retour après signalisation d'une régression, cf #1360 déjà signalé)
              Bref, quels sont vos canaux préférés (forums, mailing list, bugtracker, …) ?

              • [^] # Re: Je suis un peu étonné

                Posté par  (site web personnel) . Évalué à 1.

                Le bugtracker, ça n'est jamais oublié contrairement au reste.

                Pour le taux de retour, je pense que ça dépend surtout du bug.

              • [^] # Re: Je suis un peu étonné

                Posté par  . Évalué à 2.

                Le bug #1360 concerne un module avec login, et dépend donc de la bonne volonté du mainteneur. Je ne peux par exemple pas reproduire/corriger moi-même. Désolé pour cette mauvaise expérience du bug tracker, qui est pourtant la bonne méthode pour remonter des choses (ou IRC).

          • [^] # Re: Je suis un peu étonné

            Posté par  (site web personnel) . Évalué à 1.

            C'est intéressant.

            N'hésite pas à nous faire des retours, notamment, je pense que les erreurs devraient toutes être sur stderr, si ce n'est pas le cas on devrait le corriger. Pareil pour les codes de retour.

            Même si pour beaucoup de besoins, il devrait être plus rapide et robuste d'utiliser Python directement.

          • [^] # Re: Je suis un peu étonné

            Posté par  . Évalué à 4.

            ne pas avoir peur de choses non prévues : caractères, nouvelles infos, etc.

            Pour les "nouvelles" choses, j'ai été assez surpris en regardant également le code de skrooge qui utilise plusieurs parseurs pour différentes versions de Weboob.

            Il est pourtant normalement très simple de sélectionner les champs voulus avec l'option -s. À partir de là, aucun risque de nouveau champ à la prochaine version.

            De même, pour ces cas là :

            solde inférieur ou supérieur à une limite,

            le moteur de condition (option --condition) devrait permettre de le faire très facilement sans scripter beaucoup (avec par exemple boobank --condition "balance<400 AND id=moncomptecourant@ing" ls)

            Pour le reste, n'hésite pas à remonter les cas problématiques. La désactivation automatique a notamment été introduite pour éviter des dégâts trop importants (désactivation du compte par la banque…).

    • [^] # Re: Je suis un peu étonné

      Posté par  . Évalué à 8. Dernière modification le 22 mai 2014 à 17:56.

      Ce qui m'étonne pour ma part, ce qu'il n'y ait pas encore eu de commentaire pour critiquer le seximse du nom « Weboob ».

      Tout se perd, décidément.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # BBC

    Posté par  (site web personnel) . Évalué à 2.

    Selon
    http://weboob.org/modules#mod_quvi

    Multi-website video helper with quvi. Handles Youtube, BBC, and a lot more

    Je suppose qu'un proxy est passé pour récupérer la BBC ? Ou cela marche seulement si on est chez les grands-bretons ?

    (Je ne peux pas tester d'ici :-(

    ウィズコロナ

    • [^] # Re: BBC

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 22 mai 2014 à 19:23.

      La plupart des modules weboob supportent la configuration d'un proxy, mais je n'ai pas l'impression qu'il soit passé à libquvi.

      Tout dépend de si il faut aussi accéder à la page via le proxy, ou seulement pour l'URL de la vidéo.

      Je te conseille d'ouvrir un ticket.

      • [^] # Re: BBC

        Posté par  (site web personnel) . Évalué à 3.

        En fait j'avais envoyé à la mailing list weboob un petit programme en Python/tkinter qui faisait cela, en appelant get_iplayer avec un proxy UK.
        Comme get_iplayer est en Perl, ça n'avait pas été plus loin.

        Je me demandais donc si mon idée avait été reprise.

        Merci

        ウィズコロナ

        • [^] # Re: BBC

          Posté par  . Évalué à 3. Dernière modification le 23 mai 2014 à 10:27.

          J'ai probablement loupé ce mail sur la liste. Pour certains sites que l'on nous remonte dans les rapports de bugs, il est parfois très simple de contourner ces règles basées sur les adresses IP.

  • # Relevés OFX des banques

    Posté par  . Évalué à 4.

    Bonjour,

    J'aimerais savoir s'il est prévu d'ajouter les téléchargements des relevés bancaires au format OFX dans les modules 'boobank'. Beaucoup de banques proposent ce format, beaucoup de logiciels l'importent. Souvent, les banques ne gardent que quelque mois (3 généralement) d'historique. Si je pouvais récupérer ces relevés automatiquement (pour les importer à ma convenance dans gnucash par exemple), ça serait un gros plus pour moi.

    En tout cas, bravo pour ce qui est déjà fait. Peut-être que le nouveau Browser permettra d'ajouter plus facilement cette fonctionnalité (j'avais regardé l'ancien code et laissé tomber, j'ai tout juste réussi à faire un "patch" local pour fixer le bug #1360 que j'espère fixé dans cette nouvelle version)

    Cordialement,
    Vincent

    • [^] # Re: Relevés OFX des banques

      Posté par  (site web personnel) . Évalué à 2.

      Je pense que c'est prévu, on a déjà un système de téléchargement de factures qui pourrait être réutilisé. Je pensais faire de même avec les relevés en PDF fournis par les banques, car c'est une horreur à télécharger manuellement, et ils suppriment les anciens…

      • [^] # Re: Relevés OFX des banques

        Posté par  . Évalué à 2.

        L'intérêt de l'OFX/QIF c'est que l'on pourrait les lire directement pour sortir davantage d'historique via iter_history.

    • [^] # Re: Relevés OFX des banques

      Posté par  . Évalué à 2.

      Si je pouvais récupérer ces relevés automatiquement (pour les importer à ma convenance dans gnucash par exemple), ça serait un gros plus pour moi.

      À noter que l'on ne récupère pour le moment pas les fichiers Qif/OFX des banques (cela pourrait être fait sur certaines qui le permettent et qui donnent par ce biais plus d'infos qu'en html), mais que l'on sait en générer à partir des données extraites en html.

      Pour exporter en OFX :

      boobank -f ofx history compte@banque

      De même, -f prend aussi qif et pretty_qif comme arguments.

  • # De la bonne doc comme on en fait plus

    Posté par  (site web personnel) . Évalué à 4.

    Merci pour ce super projet.

    J'ai testé Weboorrents et j'ai utilisé l'exemple fourni pour le search … J'ai trouvé de bonnes vidéos ..

    Je vous laisse voir la doc http://weboob.org/applications/weboorrents pour plus de détails ;)

  • # Packaging

    Posté par  (site web personnel) . Évalué à 2.

    J'invite les mainteneurs voire simple utilisateurs de paquets à se signaler pour être ajoutés à la page installation. Par exemple, j'ai vu des paquets pour Fedora, mais je ne sais pas s'ils fonctionnent bien ou sont tenus à jour.

    Le paquet pour Arch Linux étant bien maintenu, j'ai changé le message du site pour qu'il fasse moins peur (devrait être bientôt visible).

    Les Gentooïstes peuvent aussi voter pour ce bug.

  • # Re-webisation

    Posté par  . Évalué à 2.

    Vous envisagez de créer des trucs genre des exports ou en json ou en RDF (format quelquonque) des données, genre pour les utiliser plus facilement hors de python et créer des APIs qui les utilisent dans d'autre langages ? Ça pourrait quasi être réinjecté dans un serveur web.

    En ignorant les problèmes de licence, ça peut être une extension cool.

    • [^] # Re: Re-webisation

      Posté par  . Évalué à 4.

      Il est déjà possible de faire des exports json, avec -f json.

  • # mise à jour depuis Debian Wheezy

    Posté par  . Évalué à 4.

    J'aime beaucoup ce projet.
    Mais depuis quelque temps, j'ai des erreurs avec la version packagée pour Debian 7.4 Wheezy, la v0.c. En particulier, videoob ne marche plus. J'ai eu un message comme quoi les backends n'étaient plus configurés puis de "Unable to load module xxx: No module named image". Bien sûr j'ai vérifié "python-image" est installé et fonctionnel.
    J'ai essayé plusieurs méthodes pour la mise à jour : remplacement des binaires, pointer sur une version plus récente du répertoire de modules mais rien n'y fait.
    Est-ce que cette nouvelle version 0.i sera packagée pour Wheezy ? Sinon, est ce qu'il y a une méthode pour mettre à jour sans passer par apt-get ?

    Help

    • [^] # Re: mise à jour depuis Debian Wheezy

      Posté par  . Évalué à 1.

      Je suis dans le même cas… J'ai essayé de l'installer à partir des sources et ça coince à la version de python-request. A suire :-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.