Paperwork : besoin de testeurs

Posté par (page perso) . Édité par Nÿco, Florent Zara et Christophe Guilloux. Modéré par Christophe Guilloux. Licence CC by-sa
36
6
mai
2013
Communauté

Paperwork est un outil pour faciliter la gestion de la paperasse de tous les jours. Il a été conçu pour les flemmards désorganisés comme moi, dans une optique de « scan & forget » : vous devriez pouvoir juste scanner un document, l'enterrer dans une pile de papiers quelconque, et quand même le retrouver le jour où vous en avez besoin. Après tout, trier est un travail de machine.

À chaque scan, Paperwork se charge de passer un coup d'OCR sur le document et de l'indexer. Comme l'OCR est imparfaite, il est aussi possible de mettre des labels sur le document. Aujourd'hui, la dernière fonctionnalité voulue pour Paperwork 0.1 a été implémentée. Maintenant, avant de faire une première release, il reste à tester tout ça. C'est là que votre aide sera précieuse : il faut des testeurs.

NdM : merci à Jérôme Flesch pour son journal.

Pour devenir testeur, il faut les choses suivantes :

  • Une distribution GNU/Linux
  • Un scanner compatible Sane
  • Savoir remplir un rapport de bug (en anglais de préférence)
  • Du temps à tuer

Attention, la branche Git à tester est la branche "testing" (branche par défaut). La branche "unstable" est celle où va commencer le développement de la 0.2.

Pour mettre l'eau à la bouche de ceux qui ne l'auraient pas déjà testé, voici une jolie capture d'écran pas-complètement-à-jour :

Paperwork en action

Merci beaucoup à ceux qui l'ont déjà testé, et merci d'avance à ceux qui vont le faire,

  • # petits retours rapides

    Posté par (page perso) . Évalué à 4.

    C'est un beau projet.

    Je l'ai testé rapidement, à partir de PDF scannés, et bien que les pdf soit de taille assez réduite, l'OCR était potable.

    Quelques commentaires en vrac :

    • les 13 dépendances, dont la plupart en en python, font un peu peur : on se dit par exemple que si l'une d'elle n'est plus supportée dans le futur, il sera difficile de péréniser la base de données que l'on se constitue grâce à cet outil.

    • je n'ai pas vu le nom d'origine des fichiers pdf importés, dans la liste des documents (juste l'image de la page) : or j'essaye justement d'avoir le nom le plus parlant possible pour m'y retrouver (par exemple avec locate si je fais une recherche sur le nom "edf" + "2013-01" je sais que ça va me retourner la ou les factures edf de janvier 2013)

    • Ça utilise gtk3, sur mon bureau xfce le rendu du toolkit est plutôt moche mais tu n'y peux rien (dans le style de ça https://bbs.archlinux.org/viewtopic.php?id=118078)

    • je n'ai pas testé le scan, uniquement l'import de PDF (je n'ai pas de scanner fonctionnel pour le moment) : j'ai essayé de faire un export ensuite de mon résultat avec OCR, ça m'a proposé une boîte de dialogue avec le nom du fichier à exporter, mais ensuite il n'y a rien sous ce nom dans le dossier que j'ai choisi.

    En fait, peut-être que j'utilise ton logiciel pour autre chose que ce dont il est conçu : j'aime l'idée de pouvoir avec un PDF mixe avec à la fois l'image et le texte OCRisé, et j'ai commencé par regarder de ce côté, mais peut-être que je devrais plutôt voir du côté de pdfsandwich

    « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

    • [^] # Re: petits retours rapides

      Posté par (page perso) . Évalué à 5.

      Pour les 13 dépendances, c'est juste une question pour moi de ne pas réinventer la roue. Quant à la pérennisation de la base de données, pour l'heure, la question ne se pose pas : l'organisation du répertoire de travail est très simple et fait usage de bêtes fichiers JPG et hOCR (text/html) (cf la doc de hacking). C'est ce répertoire qui fait référence, et l'index est automatiquement mis à jour en conséquence au démarrage de Paperwork.

      Pour les noms: L'objectif est "scan&forget", pas "scan&name&forget" :). Déjà devoir labeliser les documents est une étape de trop à mon goût (mais j'ai quelques idées pour arranger ça). Je ne souhaite pas encourager les utilisateurs à nommer systématiquement leurs documents. D'après mon expérience, les miniatures suffisent à reconnaitre un document bien plus vite qu'un nom.
      Il est toutefois possible, au besoin, d'ajouter des mots clefs sur le document, mais pas de le nommer. Si tu y tiens vraiment, tu peux renommer le dossier contenant le document différemment de la nomenclature normalement adoptée. Dans ce cas, Paperwork utilisera le nom du dossier tel quel sans essayer de le parser. Ça va faire des misères pour ordonner ensuite les documents mais bon.

      Pour les exports PDF, le texte n'est pas encore inclus dans le PDF généré. À noter aussi que lorsqu'on exporte en PDF un document qui était un PDF à l'origine, Paperwork se contente de faire une copie. (c'est vrai que je n'ai pas vraiment pensé au cas du PDF qui a l'origine ne contient pas de texte mais que une image)

  • # Forces et Faiblesses

    Posté par . Évalué à 6.

    Je suis Paperwork depuis très longtemps (en fait, depuis le premier journal là dessus), car j'aime beaucoup l'idée.

    Dans l'ensemble, l'effort n'est pas vain, mais j'aurais deux critiques :
    - l'IHM est un peu bizarre, il faudrait peut-être dessiner quelque chose sur un papier avant de la refaire, mais ce point mériterait qu'on s'y attarde;
    - l'installation via des dépendances multiples de modules Python sur GitHub force l'utilisation de virtualenv, pas très pratique actuellement.

    Ce ne sont pas des critiques très constructives, dans le sens où elles n'apportent pas de solutions. C'est un ressenti.

    Je continue de suivre les évolutions cependant, mais je tiens à préciser que mon utilisation sera beaucoup plus de l'import direct en PDF, car je peux scanner « en masse » au boulot et revenir avec ces fichiers chez moi.

    • [^] # Re: Forces et Faiblesses

      Posté par (page perso) . Évalué à 4. Dernière modification le 06/05/13 à 10:34.

      Je suis toujours ouvert à la discussion. J'invite ceux qui ont des idées à venir en discuter sur la mailing-list (en anglais, please). Pour l'IHM, l'idéal serait d'en discuter mock-ups à l'appui. Glade, bien qu'un peu buggué, peut être assez pratique pour ça.

      Pour les dépendances Python, disons juste que je préfère en avoir beaucoup plutôt que de réinventer la roue. Après, à terme, ça sera aux gestionnaires de paquets de résoudre ce problème.

    • [^] # Re: Forces et Faiblesses

      Posté par (page perso) . Évalué à 3.

      Je suis Paperwork

      Ha c'est toi !

  • # Dépendances rédhibitoire

    Posté par (page perso) . Évalué à 7. Dernière modification le 06/05/13 à 11:37.

    Salut, comme je l'avais mentionné dans un précédent journal, j'ai essayé d'installer paperwork sur une distribution Linux non basée sur Debian (Archlinux en l'occurrence) et j'ai décidé d'abandonner à cause du problème des dépendances. Étant un gars plutôt acharné et têtu, je pense que si j'en suis arrivé là, d'autres arriveront à la même conclusion, alors je développe ma critique dans l'intérêt de ce projet, que je trouve très intéressant malgré le fait que j'ai abandonné son adoption. Voici les éléments par ordre d'importance qui m'ont fait abandonner le projet "paperwork" :

    • Installation très fastidieuse : développant en Python 3, j'ai pas mal de libs compatibles Python 3 et là on part sur du Python 2 (je ne critique pas ce fait que je comprend très bien). J'ai donc 13 libs à installer, dont la plupart directement depuis les sources. c.-à-d. sans gestionnaire de paquet. Et là du coup je m'aperçois du point 2.
    • Certaines des dépendances sont abandonnées en upstream. Soit pour passer à Python 3, soit tout simplement abandonnées (J'ai nettoyé mon système depuis le tentative d'installation, alors je n'ai pas les détails, mais on pourra creuser ensemble).
    • Je fait le calcul rapide « investissement pour l'installation/temps que je vais en profiter » avant qu'une MAJ ne fasse péter mon installation : et je me dis que je n'ai pas le courage.

    Mais je n'abandonne pas là car je vois que le projet est vivant et toujours très intéressant.
    Étant également développeur de métier, je me permet de critiquer l'argument suivant :

    « Je n'embarque pas les dépendances, car je ne veux pas ré-inventé la roue ».

    Ta formulation est mauvaise, car tu peux très bien embarquer des releases des dépendances, qui à priori sont libres et compatibles avec la licence de ton logiciel. Donc si tu veux fournir un logiciel qui s'installe simplement (en exécutant un seul script) tu peux le faire ! C'est un peu de boulot, mais tu ne ré-inventeras rien du tout.

    Mais bien que mal justifié pour moi, ton choix se défend quand même, car les dépendances sont inévitable (OCR, SANE…etc) et là c'est tout le problème du développement en générale qui se pose : «  Dois-je garder des dépendances 100% à jours, ou travailler avec des releases vieillissantes? ». Je n'ai pas la réponse à cette question, car c'est une histoire de compromis. Mais ce qui est sûr, c'est que ton logiciel est difficile à installer, et que ça va incroyablement freiner son adoption. Ce qui, d'après ce que j'en ai vu, est très dommage.

    • [^] # Re: Dépendances rédhibitoire

      Posté par (page perso) . Évalué à 3.

      Certaines des dépendances sont abandonnées en upstream

      La seule que je connaisse qui semble abandonnée est PIL (corrigez-moi si je me trompe). J'ai l'intention de la remplacer par Pillow.

      Si tu en as vu d'autres, ça m’intéresse.

      « Je n'embarque pas les dépendances, car je ne veux pas ré-inventé la roue ».

      Ta formulation est mauvaise,

      En même temps, je n'ai jamais formulé ça de cette façon. Ce que je disais était "si j'ai beaucoup de dépendances, c'est parce-que je ne veux pas réinventer la roue". La question de les embarquer / packager avec Paperwork ne m'a jamais été posée jusque là.
      Quoiqu'il en soit, je continue à penser que les dépendances sont un problème qui se résoudra tout seul grâce aux gestionnaires de paquets. Si les packageurs font leur travail, un simple "apt-get install paperwork" (par exemple) suffira à l'installer.
      Je comprends qu'actuellement toutes ces dépendances sont problématiques. Mais dans l'ordre des choses, le packaging et la distribution de Paperwork ne sont pas de mon ressort.

      • [^] # Re: Dépendances rédhibitoire

        Posté par (page perso) . Évalué à 5. Dernière modification le 06/05/13 à 12:11.

        Quoiqu'il en soit, je continue à penser que les dépendances sont un problème qui se résoudra tout seul grâce aux gestionnaires de paquets.

        Pour être dans les repos, il faut que ton logiciel soit relativement connu.
        Pour être relativement connu, il faut que les gens puissent installer ton logiciel.
        Donc se reposer uniquement sur les packageurs ne va pas faire démarrer la pompe… Bienvenue dans la vraie vie des packages Linux où aucune distro n'est pareille, et où il faut que tu commences, toi, à proposer quelque chose d'installable avant que ce soit dans les repos officiels, car les testeurs que tu demandes, en ils bloquent à l'installation vu qu'il n'y a rien dans les repos!

        Non, ça ne se résoudra pas tout seul. Si tu veux des testeurs, il faut qu'ils puissent installer en dehors des repos officiels, c'est le premier test que des testeurs font (dans l’ordre des choses pour paraphraser quelqu'un ;-) )

        Mais dans l'ordre des choses, le packaging et la distribution de Paperwork ne sont pas de mon ressort.

        Dans la vraie vie, en pratique, tant que tu ne seras pas super-méga-connu, si. Bienvenue dans le développement Linux de ceux qui ne s'appellent pas Valve (par exemple).

        La packaging fait partie intégrante du développement (tu remarques que ce sont les premiers rapports de "bugs" de ton logiciel… Car ça en fait partie de ton ressort tant que personne d'autre ne se propose de le prendre en charge, ce qui semble être la cas actuellement)

        • [^] # Re: Dépendances rédhibitoire

          Posté par (page perso) . Évalué à 2.

          Si tu veux des testeurs, il faut qu'ils puissent installer en dehors des repos officiels

          Le fait est qu'un certain nombre de personnes ont déjà réussi à l'installer. Essentiellement des utilisateurs de Debian, Ubuntu et Fedora je présume. ArchLinux est plus problématique vu que la version par défaut de Python sur cette distribution est Python 3. C'est là encore un problème qui se résoudra de lui-même quand je ferais le passage à Python 3.

          Le mieux que je puisse faire est de documenter la liste des dépendances, et pour les distributions les plus courantes, indiquer comment les installer. Je n'ai définitivement pas l'intention de me prendre la tête à faire un meta-package volumineux qui ne fonctionnera que sur une distribution sur deux. Je n'ai pas non plus l'intention de faire moi-même des paquets pour chaque distribution/architecture.

          Par contre, une fois la 1ère release faite, j'ai l'intention d'aller discuter avec les mainteneurs Debian, pour voir si l'un d'entre eux serait assez charitable pour packager Paperwork et quelques-unes de ses dépendances. (pourquoi Debian ? Parce-que c'est la distribution que j'utilise). Si l'un d'entre eux le fait, tant mieux, sinon tant pis.

          tu remarques que ce sont les premiers rapports de "bugs" de ton logiciel

          Euh non. Les 1ers rapports de bug sur Paperwork sont bien plus vieux et n'ont rien à voir.

          • [^] # Re: Dépendances rédhibitoire

            Posté par (page perso) . Évalué à 2.

            Par contre, une fois la 1ère release faite, j'ai l'intention d'aller discuter avec les mainteneurs Debian, pour voir si l'un d'entre eux serait assez charitable pour packager Paperwork et quelques-unes de ses dépendances. (pourquoi Debian ? Parce-que c'est la distribution que j'utilise). Si l'un d'entre eux le fait, tant mieux, sinon tant pis.

            Entre un logiciel facilement portable et un logiciel dédié Debian, les mainteneurs Debian auront vite fait leur choix je pense. Bon, faudrait-il encore qu'il existe un concurrent sérieux à Paperwork (en fait, j'en sais rien). Mais tout ça pour montrer que la portabilité de ton logiciel va aussi dans l'intérêt de la communauté Debian.

            • [^] # Re: Dépendances rédhibitoire

              Posté par (page perso) . Évalué à 5.

              Je n'ai jamais dit que je comptais en faire un logiciel dédié Debian. J'ai juste dit que Debian est la distribution que j'utilise et sur laquelle je le développe, et que c'est donc la seule dans laquelle ça m'importe vraiment de voir Paperwork packagé. Si d'autres le packagent aussi, tant mieux, sinon tant pis.

              Pour info, je teste aussi de temps en temps Paperwork sur Fedora et Ubuntu.

          • [^] # Re: Dépendances rédhibitoire

            Posté par . Évalué à 3.

            Par contre, une fois la 1ère release faite, j'ai l'intention d'aller discuter avec les mainteneurs Debian, pour voir si l'un d'entre eux serait assez charitable pour packager Paperwork et quelques-unes de ses dépendances.

            Je comprend que tu n'aies pas envie de maintenir des paquets pour toutes les distros, mais:

            • faire un paquet Debian n'est pas dur et est totalement automatisable.
            • faire des paquets pour tes dépendances te fait gagner du temps en te permettant de garder un système plus propre (comme elles sont intégrées dans ton gestionnaire de paquet, tu peux les virer facilement, les mettre à jour, et les réinstaller avec des paquets que tu auras actualisé avec des scripts: rien à faire donc)
            • faire un paquet pour ton application te permets de la déployer plus simplement sur plusieurs machines (entre mon netbook, ma tour et mon ordinosaure je trouve ça utile)
            • faire des paquets en général te permets de faciliter l'installation pour tout le monde et donc d'avoir plus de retours.

            Pour le "comment faire":
            Déjà, tu as pas besoin de t'embêter avec l'architecture cible, vu que tu sembles utiliser python, donc le nom de ton architecture sera "all".

            Ensuite, il y a pleins de solutions, dont certaines qui demandent d'apprendre des procédures (les solutions propres ça, celles que je n'utilise pas ;) ) et d'installer des paquets… perso, j'ai eu la flemme, alors j'ai ouvert une archive (7z ou tar, choisi ton arme), j'ai regardé dedans, j'ai vu que c'était simple alors j'ai semi-automatisé la procédure. C'est crade dans le principe, mais dans la pratique ça marche proprement (et c'est ça qui m'intéresse au final).

            J'ai eu besoin à un moment d'utiliser une dépendance à une lib (pluma-framework) qui n'était pas packagée (ni même testée sous autre chose que windows, pour être précis, et en plus hébergé sur un svn… d'où le "fork" qui me sers de laboratoire pour fixer les bugs que je remonte ensuite upstream avec les patchs) pour laquelle j'ai créé un patch.

            J'ai du coup fait quelques scripts à la va-vite, si tu es intéressé, tu peux les récupérer et les adapter, ils sont ici.

            Tu noteras que j'ai créé un répertoire par architecture ciblée, puis pour chaque architecture un nouveau pour chaque paquet final. Ce répertoire de paquet final contiens 2 choses: un "squelette" de l'arborescence qui sera affectée par le paquet, et un dossier "DEBIAN" qui lui contiens juste un fichier "control". Il te suffit de modifier ce fameux fichier, et de lancer les scripts (que tu auras naturellement lus et adaptés avant, vue leur tronche, c'est vraiment pas compliqué… tu noteras que j'ai bien dis qu'ils sont faits à la va-vite hein… faudrait que je les améliore, mais je ferai ça à mon prochain projet je pense, ou alors j'apprendrai à faire des trucs propres) et tu récupéreras en sortie tes paquets "deb".

            Note: je n'ai utilisé que le fichier "control" qui ne contiens donc pas de signature. Une façon plus propre de faire les choses aurait été de créer un fichier ("sum" il me semble) qui contiens les hash des fichiers contenus dans ton paquet, et tu aurais ainsi même pu permettre de certifier que les fichiers n'ont pas été modifiés lors du transfert…

          • [^] # Re: Dépendances rédhibitoire

            Posté par (page perso) . Évalué à 2.

            Pour info, construire un paquet en Python est assez simple, quand on a un fichier setup.py déjà existant.

            Il faut utiliser (python-distribute) et la commande supplémentaire bdist_stdeb.

            Après, python setup.py permet de construire en ligne de commande des paquets .deb, .rpm, .tar.gz (binaire ou source), .exe, …

        • [^] # Re: Dépendances rédhibitoire

          Posté par . Évalué à 3.

          il faut qu'ils puissent installer en dehors des repos officiels

          Je ne renie pas, car j'en sais foutre rien, mais alors qu'est ce que cela me surprend….

          Si tant est qu'on ai parlé d'une lib machin du sous système y nécessaire au démarrage, je n'aurais pas sourcillé d'un poil.

          Mais là non , son logiciel est situé à la toute fin de la chaîne des dépendances, il est construit autour des gestionnaires de paquets, et pourtant il doit faire l'inverse pour être éventuellement intégrable.

          On peut même imaginer que sans le gestionnaire de paquets pour rapidement lui fournir un environnement de développement lui permettant de ce concentrer sur sa valeur ajoutée,
          le logiciel n'aurait jamais vu le jour.

          Bref, j'aurais bien aimé en comprendre la raison avant de me laisser aller à quelques conclusions hâtives.

          • [^] # Re: Dépendances rédhibitoire

            Posté par (page perso) . Évalué à 2.

            Mais là non , son logiciel est situé à la toute fin de la chaîne des dépendances, il est construit autour des gestionnaires de paquets, et pourtant il doit faire l'inverse pour être éventuellement intégrable.

            « Autour d'apt-get » serait plus juste.

            On peut même imaginer que sans le gestionnaire de paquets pour rapidement lui fournir un environnement de développement lui permettant de ce concentrer sur sa valeur ajoutée,
            le logiciel n'aurait jamais vu le jour.

            Ça n'empêche pas qu'on va vouloir le tester avant de l'injecter dans les dépôts officiels.

            • [^] # Re: Dépendances rédhibitoire

              Posté par . Évalué à 2.

              Autour de dpkg le serait encore plus :)

            • [^] # Re: Dépendances rédhibitoire

              Posté par . Évalué à 1.

              oui, je sais pas trop comment ca fonctionne, je prend pour comparaison des gestionnaire de dependances genre npm ou composer.
              Tout y est fait pour t'amener à publier ta production.

              A lire zenitram, faire un projet pour desktop linux semble hautement plus compliqué… en tout cas rédhibitoire en ce qui me concerne.

      • [^] # Re: Dépendances rédhibitoire

        Posté par (page perso) . Évalué à 3. Dernière modification le 06/05/13 à 13:15.

        En même temps, je n'ai jamais formulé ça de cette façon. Ce que je disais était "si j'ai beaucoup de dépendances, c'est parce-que je ne veux pas réinventer la roue". La question de les embarquer / packager avec Paperwork ne m'a jamais été posée jusque là.

        Mea culpa ! Effectivement la question n'était pas posée comme ça, mais finalement l'utilisateur s'en fout un peu qu'il y est beaucoup de dépendances, si le logiciel est facile à installer, est à jours, et fonctionne correctement.

        Quoiqu'il en soit, je continue à penser que les dépendances sont un problème qui se résoudra tout seul grâce aux gestionnaires de paquets. Si les packageurs font leur travail, un simple "apt-get install paperwork" (par exemple) suffira à l'installer.

        Je rejoins Zenitram sur le fait que si tu attends que ça tombe du ciel, tu vas freiner l'adoption de ton logiciel.

        Mais dans l'ordre des choses, le packaging et la distribution de Paperwork ne sont pas de mon ressort.

        Pour moi, ça veut dire que tu n'as pas envie de faire le packaging (ça je crois qu'on l'a bien compris) et que tu t'en fout d'avoir beaucoup d'utilisateurs tant que tu peux faire marcher le projet. J'ai peur que ce genre de politique ne soit pas très vendeur.

        Finalement, pour moi le problème majeur est ailleurs : prenons les choses du point de vue d'un packageur potentiel (j'avoue que je me suis posé la question, mais je suis moyennement motivé):

        • 13 dépendances à packager : c'est énorme ! Allez, disons que 4 ou 5 sont déjà disponibles sur les dépôts des principales distrib Linux. Il en reste encore 8 ou 9 ! Et ça pour chaque distrib ciblée. Tu te représentes la quantité de travail? Alors qu'avec un poil de volonté du développeur on pourrait avoir un paquet par distrib à faire. Même si le problème des dépendances est difficile (j'ai pas de solution miracle), ça donne moyennement envie.
        • Portabilité ? : Le logiciel est en Python, donc il pourrait potentiellement viser Windows et/ou Mac OS. Oui mais avec la gestion actuelle des dépendances, c'est déjà un boulot de titan de le packager pour des distribs non debian. La encore je suis un peu déçu.
        • Gestion du projet : La gestion des dépendances (Quelles libs on utilise? Quelles libs on peut virer? Quelles versions?), c'est le développeur qui doit les faire, j'espère qu'au moins la dessus on est d'accord. Seulement si le développeur ne tient compte que du code et pas du packaging, le logiciel peut vite devenir une horreur à packager. Par exemple si le dev choisi d'intégrer une lib originale que personne n'utilise à chaque release.
        • Le côté ingrat du boulot : Finalement, je préfère largement coder que packager, et je suis sûr que c'est le cas d'une majorité de gens. Donc si le travail n'est pas préparé par le project leader et qu'il n'est même pas valorisé, il y a peu de chance que je le fasse.

        Encore une fois, je salue ton travail car il y a du mérite ! Mais je pense que mes critiques sont fondées, en tout cas c'est la réflexion que je me suis faite. Bref le problème du packaging est difficile dans ton cas, en plus c'est du Python et c'est pas le moment adéquate pour vendre du Python. Mais je suis sûr qu'en y mettant les formes et en fournissant un peu de travail, tu peux arriver à un résultat très prometteur.

        • [^] # Re: Dépendances rédhibitoire

          Posté par (page perso) . Évalué à 2. Dernière modification le 06/05/13 à 13:56.

          Tu te représentes la quantité de travail? Alors qu'avec un poil de volonté du développeur on pourrait avoir un paquet par distrib à faire

          Je ne connais pas les politiques exactes de chaque distribution, mais je suis presque sûr que pour une distribution comme Debian, c'est une violation de leur politique. À ma connaissance, c'est toujours un package par librairie ou programme. Il me semble clair que pour eux, il est hors de question de faire un paquet contenant un programme et 10 librairies. Sinon l'intérêt des dépendances se perd, et on en arrive à ce que font les installateurs Windows ou PC-BSD.
          Au final, que je package ou pas Paperwork avec ses dépendances n'aidera en rien les packageurs des distributions.

          Portabilité ? : Le logiciel est en Python, donc il pourrait potentiellement viser Windows et/ou Mac OS

          Nop. Mon poil dans la main est trop gros pour supporter des OS propriétaires. Si quelqu'un veut le faire, qu'il se fasse plaisir, mais je ne le ferais pas. Par contre, je veux bien faire du support pour cette personne si elle en a besoin et je ne suis pas contre l'inclusion de patchs ayant pour but la portabilité.

          Gestion du projet : La gestion des dépendances (Quelles libs on utilise? Quelles libs on peut virer? Quelles versions?), c'est le développeur qui doit les faire, j'espère qu'au moins la dessus on est d'accord. Seulement si le développeur ne tient compte que du code et pas du packaging, le logiciel peut vite devenir une horreur à packager. Par exemple si le dev choisi d'intégrer une lib originale que personne n'utilise à chaque release.

          Sur ce point on est d'accord. C'est pour ça que j'essaye de maintenir une liste des dépendances aussi complète que possible. C'est aussi pour ça que j'essaye d'éviter les dépendances ésotériques et que je favorise autant que possible les librairies déjà disponibles dans Debian. (je n'aime pas plus qu'un autre avoir 25 librairies installées en dehors de mon gestionnaire de paquets)

          • [^] # Re: Dépendances rédhibitoire

            Posté par (page perso) . Évalué à 1.

            Au final on est d'accord sur la technique, je suis d'accord sur le fait que la plupart des dépendances doivent être packagées à part. Pour les OS proprio je suis d'accord aussi.

            Je voulais juste montrer que c'était dur de faire un paquet de ce logiciel. Et honnêtement, je pense que si tu te fends de faire un paquet Debian pour ta V1 et que tu repasses demander des testeurs, tu auras beaucoup plus de succès. Y compris auprès des non debianistes :)

            • [^] # Re: Dépendances rédhibitoire

              Posté par . Évalué à 3.

              Je voulais juste montrer que c'était dur de faire un paquet de ce logiciel.

              Pas tant que ça, dès lors que l'on connaît les dépendances du dit logiciel. Ou alors, tu ne parles des fichiers deb… (cf plus haut ou j'explique comment j'ai fait un truc à la va-vite…)

              On oublie généralement dans les intérêts que ça permets aussi de simplifier la vie du dev: déjà, plus de plaintes "ouin y'a pas de paquet pour debian" (y'a toujours les mêmes pour fedora et arch, forcément…) mais surtout ça simplifie la galère avec les versions.

              Pour le fait d'avoir plus facilement des testeurs, je suis assez d'accord par contre.

              • [^] # Re: Dépendances rédhibitoire

                Posté par (page perso) . Évalué à 1. Dernière modification le 06/05/13 à 16:37.

                Pas tant que ça, dès lors que l'on connaît les dépendances du dit logiciel. Ou alors, tu ne parles des fichiers deb… (cf plus haut ou j'explique comment j'ai fait un truc à la va-vite…)

                J'entends de faire un paquet par dépendances :)

                Mais cela dit, je suis d'accord sur le fait qu'il vaut mieux avoir un paquet qui embarque toutes les dépendances que pas de paquet du tout. Dans ce cas, je ferais juste attention à utiliser un environnement spécifique pour le logiciel en question, afin que les libs embarquées ne polluent pas l'environnement de l'utilisateur (Par chance, Python se prête très bien à ce genre de gymnastique). Je pense au cas où on installe une lib embarquée avec un logiciel arbitraire, puis qu'on installe cette même lib par la suite via le gestionnaire de paquet. Ça m'est déjà arrivé en Java et c'est assez subtile à trouver comme bug !

                Finalement on a trouvé une solution assez propre pour Paperwork :) Y a plus qu'à !

                • [^] # Re: Dépendances rédhibitoire

                  Posté par . Évalué à 1.

                  J'entends de faire un paquet par dépendances :)

                  Mais cela dit, je suis d'accord sur le fait qu'il vaut mieux avoir un paquet qui embarque toutes les dépendances que pas de paquet du tout.

                  Pour le 1er point, je maintiens. C'est juste un peu chiant la première fois parce qu'il faut paramétrer chaque paquet que l'on souhaite générer, mais après, il suffit de faire 2-3 scripts et ça se fait tout seul… après tout, dans un paquet debian, a part la version et parfois des dépendances à ajouter/supprimer, rien ne change.
                  La version peut s'automatiser à coups de sed/awk je pense, et les dépendances, de toutes façon quand on mets à jour on les vérifies… ou alors on s'expose à des emmerdes a n'en plus finir.

                  Pour le 2nd, je n'ai pas d'avis. Personnellement, je pense que dès l'instant ou l'on fait 1 paquet pour un logiciel, il n'y a pas grand chose qui empêche de faire des paquets pour les autres: le principe est le même, il n'y a que les fichier DEBIAN/control à modifier, ce n'est pas la mer à boire tout de même.

                  En revanche, je me suis fais la réflexion il y quelques minutes que, depuis le multi-arch, mes scripts ont une forte chance de tout péter si l'utilisateur installe d'abord i386 puis amd64, ou vice versa, sans supprimer l'ancienne (en gros: s'il fait n'imp, mais un utilisateur, c'est comme un ordinateur, si on part du principe qu'il va deviner ce qu'il faut faire, on s'expose aux emmerdes et aux crashs)… va falloir que j'ajoute une dépendance de conflit, ou que je fasse que la lib que j'ai empaquetée soit compatible multi-arch… je pense que je vais plutôt ajouter la dépendance de conflit, ça sera plus simple :D (faut que je me remette à autorealm un de ces 4 d'ailleurs)

          • [^] # Re: Dépendances rédhibitoire

            Posté par . Évalué à 1.

            Je ne connais pas les politiques exactes de chaque distribution, mais je suis presque sûr que pour une distribution comme Debian, c'est une violation de leur politique.

            Non…

            … et oui, car je n'ai constaté que cet état de faits pour de très petits logiciels, pas pour des libs.

            • [^] # Re: Dépendances rédhibitoire

              Posté par . Évalué à 2.

              C'est normal que tu ais constaté cela que pour des collections de logiciels et non pas pour des librairies : c'est la politique de Debian.
              Il est autorisé de faire un paquet pour une collection de petits outils sous la même licence et dans le même domaine (tous les -utils en général).
              Cependant, sous Debian, il est contraire à la politique d'embarquer les librairies de dépendance dans le paquet, et ce même si le développeur les a joint à son code source. Ce type de paquet sera systématiquement rejeté.

              En effet, avoir plusieurs outils liés dans un paquet ne pose pas de problème (soit tu installes tout, soit rien, c'est le seul problème), mais si j'embarque les librairies dans mon logiciel, cela veut dire que je vais me retrouver avec potentiellement plusieurs versions des librairies sur mon poste… d'où des éventuels conflits, perte d'espace, problématique de mise à jour, …

              La plupart des autres distributions ont une politique très semblable, généralement juste peut être un peu plus laxiste que Debian ;).

              • [^] # Re: Dépendances rédhibitoire

                Posté par . Évalué à 1.

                Je le sais, et très honnêtement, je trouve cette politique tout sauf stupide.
                En fait, je répondait bien à la partie que j'ai citée, mais j'aurai dû étendre la citation pour qu'elle englobe ceci: "À ma connaissance, c'est toujours un package par librairie ou programme. "

  • # Import de photos

    Posté par . Évalué à 4.

    Je n'ai pas de scanner, mais un téléphone qui comme la grande majorité des smartphones actuels fait des photos en grande résolution. Est-il possible d'importer les photos dans Paperwork et de les recadrer automatiquement, en reconnaissant la feuille de papier ?

    • [^] # Re: Import de photos

      Posté par (page perso) . Évalué à 4.

      Il est possible d'importer des images. Il n'y a toutefois pas de recadrage automatique. Paperwork permet juste une édition minimaliste des pages/images : rognage et rotation de 90/180/270 degrés.

      Maintenant, je ne suis pas sûr qu'utiliser son téléphone pour scanner des documents soit une bonne idée. J'ai déjà entendu et lu plusieurs personnes se plaindre du temps que ça prend pour scanner les piles de papiers qu'ils avaient accumulées jusque là avec un scanner. Je ne peux qu'imaginer le temps que ça prendrait avec un téléphone (temps de transfert sur l'ordinateur et import dans Paperwork, photos partiellement floues à refaire, etc).

      • [^] # Re: Import de photos

        Posté par . Évalué à 2.

        Si j'avais un scanner, je l'utiliserai effectivement. Le problème est que c'est petit chez moi, que mon téléphone me suffit pour scanner mes fiches de paye, que je ne suis pas tout le temps chez moi et que si je peux économiser quelques dizaines d'euros, ce n'est pas plus mal. D'où l'utilisation du téléphone. Je ne pense pas être le seul à faire ça.

        Je peux essayer de te faire un script pour redresser l'image automatiquement. Si tu veux bien l'intégrer dans Paperwork, je le code et je test le logiciel après.

        • [^] # Re: Import de photos

          Posté par . Évalué à 2.

          il existe des montage sur le net pour utiliser un apn comme scanner. ça permet démettre l'appareil à la bonne distance et d'avoir le bon cadrage. j'imagine qu'il faut faire les réglages en fonction de sa configuration mais après ça doit gagner un temps fou.

  • # Héhé

    Posté par (page perso) . Évalué à 4.

    Salut Jérôme, je voulais te dire que j'aime beaucoup ton site web

    Mais tu pourrais au moins mettre un lien vers Paperwork, quand même :)

    Je te donne le code source en bonus ^v^

    "<a href="https://github.com/jflesch/paperwork#readme">Paperwork</a> is a tool to make papers searchable."

  • # Dépendances pour Fedora ?

    Posté par (page perso) . Évalué à 1.

    Si quelqu'un a déjà compilé la liste des paquets Fedora à installer pour combler les dépendances de Paperwork, je suis preneur !
    Sinon, je tenterai de m'y coller.

  • # Au sujet d'Archlinux

    Posté par (page perso) . Évalué à 1.

    Le sujet a été abordé précédemment mais voilà : je suis bien intéressé par ce projet, je suis sous Arch mais je suis pas très fort. Si quelqu'un a les compétences/bonne volonté pour écrire un "howto install", je lui en serai infiniment reconnaissant !

    Mon 1er commentaire sur linuxfr … ça fait drôle.

    • [^] # Re: Au sujet d'Archlinux

      Posté par (page perso) . Évalué à 2.

      Voila l'idée.

      pacman -S python2-virtualenv python2-distribute git tesseract-data-fra tesseract-data-fra python2-cairo python2-pygit python2-imaging glade
      
      pip install pycountry enchant levenshtein whoosh
      
      # là, c'est la partie qui bloque pour l'instant parce que les packages ne sont pas tout à fait au point
      pip install -e git+git://github.com/jflesch/pyocr.git#egg=pyocr
      pip install -e git+git://github.com/jflesch/pyinsane.git#egg=pyinsane
      pip install -e git+git://github.com/jflesch/paperwork.git#egg=paperwork
      
      
  • # purge

    Posté par . Évalué à 2.

    suggestion:
    Le truc qui pourrait être intéressant, c'est de pouvoir mettre une date de péremption sur un document ou une catégorie de document.

    Pour un mec qui vient de passer 4h dimanche à classer des papiers, je suis très attentif à l'évolution de ce projet :)

  • # OCR

    Posté par . Évalué à 0.

    Quel logiciel d'OCR est utilisée ?

  • # rpm pour Mageia 2

    Posté par . Évalué à 2.

    J'ai preparè des paquets pour Mageia 2.
    Le paperwork et les dependences
    Touts sont disponibles ici:
    http://www.mageia-gr.org/rpm/2/noarch/

    Par contre j'ai passè beaucoup de temps pour faire les rpm de toutes les dependences et je n' ai pas eu le temp encore de faire des tests. J'ai essayè de passer le ocr sur un document scannè et c' a marchè correctement

    C'est une application laquelle je voudrais vraiment pour organiser mes papiers car je scan tout, mais difficile à retrouver apres …

    Je voudrais poser une question:

    Quand on passe un document scannè déjà dans paperwork et on fait un Redo OCR, ca veut dire que le contenu du document est désormais recherchable depuis d'autres applications ? example le recoll (utilise xapian)?

    En fait, je n ai pas compris comment les documents sont exploitables à la suite.
    Si il faut avoir tout les documents importès dans la liste à gauche du paperwork ca serait bien si on peut inserer plusiers documents à la fois et non un par un

    Actuelement, j'ai mes documents organisès dans des dossiers dans le dossier Dropbox.

  • # PKGBUILD pour Arch Linux dispo dans AUR

    Posté par . Évalué à 3.

    J'ai mis le PKGBUILD de paperwork-git pour Arch linux sous AUR (https://aur.archlinux.org/packages/paperwork-git/) avec les 2 ou 3 paquets qui manquaient.

    Une chose qui me manque est de pouvoir importer tout une arborescence de PDF, car un par un c'est long !

  • # Installé sur Arch

    Posté par . Évalué à 1.

    Salut,

    J'ai installé paperwork sur Arch via le paquet AUR : j'ai du corriger le PKGBUILD, je t'invite à le mettre à jour si tu t'en occupes, 2 paquets sont faux et il manque pyenchant.
    Je vais essayé de tester ça

  • # Premier commentaire

    Posté par . Évalué à 0.

    J'ai découvert Paperwork via Linux Essentiel. Bravo, ça a l'air très intéressant !
    Je teste dès ce week-end (si j'ai du temps)…

    • [^] # Re: Premier commentaire

      Posté par . Évalué à 0.

      Arf !
      J'ai tenté l'installation ce soir, mais ça n'a rien donné…
      Le apt-get ne trouve pas les paquets. Etant sur une 10.04, je me rends compte qu'il va falloir changer quelque chose et pas qu'un peu !

      C'est dommage, je me faisais une joie de me débarrasser de mes papiers. Mais l'idée est intéressante, très intéressante…

Suivre le flux des commentaires

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