Projet

Général

Profil

Development #44020

développer notre petit module de lecture ods

Ajouté par Frédéric Péters il y a presque 4 ans. Mis à jour il y a plus de 3 ans.

Statut:
Solution proposée
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
12 juin 2020
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non
Club:
Non

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.


Demandes liées

Lié à Chrono - Development #44170: import CSV, BOMFermé17 juin 2020

Actions
Lié à Passerelle - Bug #14404: connecteur tableur : perfs déplorables sur un fichier odsNouveau21 décembre 2016

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

Actions
Lié à Authentic 2 - Development #45064: Utiliser tabularfile pour revoir les exportsRejeté13 juillet 2020

Actions

Historique

#1

Mis à jour par Benjamin Dauvergne il y a presque 4 ans

Je suis intéressé.

#2

Mis à jour par Frédéric Péters il y a presque 4 ans

#3

Mis à jour par Frédéric Péters il y a presque 4 ans

  • Lié à Bug #14404: connecteur tableur : perfs déplorables sur un fichier ods ajouté
#4

Mis à jour par Mikaël Ates il y a plus de 3 ans

  • Lié à Support #44559: Lors de l'import d'un CSV, conserver les sauts de lignes du champs description. ajouté
#5

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

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

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

  • Statut changé de Nouveau à 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

Mis à jour par Frédéric Péters il y a plus de 3 ans

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

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

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

Mis à jour par Frédéric Péters il y a plus de 3 ans

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

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

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

Mis à jour par Frédéric Péters il y a plus de 3 ans

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

Mis à jour par Nicolas Roche (absent jusqu'au 3 avril) il y a plus de 3 ans

#13

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

  • Statut changé de Solution validée à Solution proposée
  • Assigné à mis à Benjamin Dauvergne

Formats disponibles : Atom PDF