Project

General

Profile

Development #44020

développer notre petit module de lecture ods

Added by Frédéric Péters over 1 year ago. Updated about 1 year ago.

Status:
Solution proposée
Priority:
Normal
Category:
-
Target version:
-
Start date:
12 Jun 2020
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No
Club:
No

Description

On fait à quantité d'endroits de l'import CSV et plouf le BOM, plouf le séparateur, plouf l'encodage.

On devrait avoir un module à l'API proche de l'API des CSV, qui fonctionne et point, sans mille dépendances etc. qu'on utiliserait, et on arrêterait avec les CSV.


Related issues

Related to Chrono - Development #44170: import CSV, BOMSolution déployée17 Jun 2020

Actions
Related to Passerelle - Bug #14404: connecteur tableur : perfs déplorables sur un fichier odsNouveau21 Dec 2016

Actions
Related to Chrono - Support #44559: Lors de l'import d'un CSV, conserver les sauts de lignes du champs description.Rejeté29 Jun 2020

Actions
Related to Authentic 2 - Development #45064: Utiliser tabularfile pour revoir les exportsNouveau13 Jul 2020

Actions

History

#1

Updated by Benjamin Dauvergne over 1 year ago

Je suis intéressé.

#2

Updated by Frédéric Péters over 1 year ago

#3

Updated by Frédéric Péters over 1 year ago

  • Related to Bug #14404: connecteur tableur : perfs déplorables sur un fichier ods added
#4

Updated by Mikaël Ates over 1 year ago

  • Related to Support #44559: Lors de l'import d'un CSV, conserver les sauts de lignes du champs description. added
#5

Updated by Benjamin Dauvergne over 1 year ago

http://git.entrouvert.org/ods.git/

J'ai repris wcs.qommon.ods en partie (je n'ai pas réussi à voir l'effet de la déclaration de l'élément table:table-column et des styles DateColumn/DateTimeColumn, si ça reste utile je le remettrais) pour l'écriture mais avec une API qui ressemble plus à csv.writer() et la partie lecture est originale, avec par rapport à csv la possibilité de conserver le typage des cellules (et donc d'obtenir des int, date, datetime, etc.. ça n'est pas obligatoire mais ça donne quelque chose de symétrique avec la partie écriture).

Les deux fonctionnent en mode push/pull pour ne consommer aucune mémoire ou presque.

Là ce qu'il faudrait surtout c'est plus de fichiers tests pour les tests en lecture. Je note déjà que rowspan/colspan ne sont pas supportés (et certainement plein d'autres choses).

#6

Updated by Benjamin Dauvergne over 1 year ago

  • Status changed from Nouveau to Solution validée

J'ai mis ça dans un namespace finalement, pas envie de polluer le namespace de base avec ods, http://git.entrouvert.org/eo-utils.git/ le packaging debian est fait, l'API est décrite dans le README, ça supporte python 3.5 (stretch) au cas où.

PS: en écriture ça supporte tout ce que fait le module wcs.qommon.ods actuellement (j'ai ajouté la possibilité d'avoir de liens).

#7

Updated by Frédéric Péters over 1 year ago

Quand j'écrivais "petit module", je pensais plutôt en fait à un "package", qui ne soit pas fourre-tout, on aurait trouvé un nom, genre tabularfile, et ça aurait ouvert des directions supplémentaires, je pense là à y gérer les CSV avec tout le brol bom/encodage/etc., ça serait allé dans une classe AutoReader, ce qui est le truc qui permettrait à mon sens in fine de retirer cette partie de nos applications.

Là le nom fourre-tout entraine pour moi une obsolescence déjà programmée, à la djommon dans le passé.

#8

Updated by Benjamin Dauvergne over 1 year ago

Frédéric Péters a écrit :

On devrait avoir un module à l'API proche de l'API des CSV, qui fonctionne et point, sans mille dépendances etc. qu'on utiliserait, et on arrêterait avec les CSV.

Je veux bien mais si l'objectif était de faire un tablib en mieux (sans le foutoir dans vendor/ et les performances aléatoires) il fallait l'écrire dès la description; là ça sonnait plutôt comme « Hors d'ODS, point de salut ». Là je suis aller plus loin en voulant coller à ce que fait w.c.s. pour ses exports, faut voir l'API qu'on veut, on peut s'en tenir pour l'API générique à du texte en entrée/texte en sortie ou alors prévoir un minimum de sérialisation/détection de type pour CSV (genre int, float, date iso8601 et datetime iso8601).

Sur le nom, je n'ai pas de souci à passer à tabularfile, sauf que ça nous met pas mal en avant du pypi avec tablib, pyexcel et leurs copains; mais je pense aussi qu'au delà des expériences djommon/qommon on a un besoin de partager du code, genre les filtres ou les bouts de code qu'on copie partout sans en maintenir la cohérence comme l'API de signature de Publik, qui diffère d'ailleurs maintenant entre wcs et les autres briques.

#9

Updated by Frédéric Péters over 1 year ago

Oui, c'est « Quand j'écrivais "petit module", je pensais plutôt en fait à un "package" » qui a mené confusion, ok. (aussi, ce ticket n'avait pas de personne assignée mais je n'imaginais pas qu'il soit pris sans discussion, et j'ai pris le "je suis intéressé" comme étant ton intérêt que quelqu'un/e prenne le ticket, pas comme quoi tu allais le prendre).

En même temps j'écrivais "lecture", donc l'interprétation de ce que j'ai écrit a de toute façon été assez libre.

Je n'ai pas compris ton commentaire sur le nom, c'est la crainte de faire un module qui soit utilisé par d'autres, ou de guider d'autres indirectement d'autres personnes vers un module qui ne ferait pas "tout" ?

Sur ce dernier point, ma réponse pourrait être d'en taper en description "Opiniated read/write support of tabular formats", le "opiniated" étant le truc à la mode pour proclamer qu'on gère comme on veut.

Bref, je suis pour un module dédié, d'abord à la lecture, d'abord à l'ods (mais en fait tout de suite au csv pour remplacer d'un coup la lecture CSV qu'on a dans nos modules, sans introduire deux modes, csv compat puis ods nouveau).

#10

Updated by Benjamin Dauvergne over 1 year ago

Frédéric Péters a écrit :

Oui, c'est « Quand j'écrivais "petit module", je pensais plutôt en fait à un "package" » qui a mené confusion, ok. (aussi, ce ticket n'avait pas de personne assignée mais je n'imaginais pas qu'il soit pris sans discussion, et j'ai pris le "je suis intéressé" comme étant ton intérêt que quelqu'un/e prenne le ticket, pas comme quoi tu allais le prendre).

En même temps j'écrivais "lecture", donc l'interprétation de ce que j'ai écrit a de toute façon été assez libre.

Je n'ai pas compris ton commentaire sur le nom, c'est la crainte de faire un module qui soit utilisé par d'autres, ou de guider d'autres indirectement d'autres personnes vers un module qui ne ferait pas "tout" ?

J'ai une haute opinion des annuaires de paquets, habitué à CPAN dans ma jeunesse, pypi n'a pas le niveau d'organisation et de qualité de CPAN en général mais je vois d'un mauvais oeuil de s'approprier un terme générique comme tabularfile (ce qu'a fait tablib) et de ne pas mener le projet sous-entendu à bien, si ça s'appelle eo-tablib, ça me gêne moins.

Sur ce dernier point, ma réponse pourrait être d'en taper en description "Opiniated read/write support of tabular formats", le "opiniated" étant le truc à la mode pour proclamer qu'on gère comme on veut.

Mouais.. ça prouve juste que les pythoneurs ne sont pas des gens très sérieux.

Bref, je suis pour un module dédié, d'abord à la lecture, d'abord à l'ods (mais en fait tout de suite au csv pour remplacer d'un coup la lecture CSV qu'on a dans nos modules, sans introduire deux modes, csv compat puis ods nouveau).

Ok. Je ne vais pas jeter le code qui écrit et qui fonctionne, je vais en avoir besoin dans a2, mais pour l'aspect générique je ne vais faire que la lecture:
  • détection du type de fichier ODS ou CSV, avec gestion BOM et dialect
  • pas de détection du type des colonnes
#11

Updated by Frédéric Péters over 1 year ago

Pour le nom de fait le namespacing est rare (genre sorl.thumbnail dans ce qu'on utilise, mais un peu au-delà, les modules plone, eux, sont généralement namespacés); mais clairement oui quand j'écris "tabularfile" c'est bien en imaginant "mener le projet sous-entendu à bien"; et quand je précise le "opiniated" par la suite, c'est pour me libérer des "sous-entendus" tiers.

(et je n'aime pas vraiment le préfixe eo qui attache (trop) le module à l'entreprise).

Mais si tabularfile pose vraiment soucis, des variantes différentes / plus longues peuvent être imaginées.

#12

Updated by Nicolas Roche about 1 year ago

#13

Updated by Benjamin Dauvergne about 1 year ago

  • Status changed from Solution validée to Solution proposée
  • Assignee set to Benjamin Dauvergne

Also available in: Atom PDF