Cédric Krier a écrit 124 commentaires

On n'est pas vraiment contre un changement de format mais il faut que ça apporte un plus sans retirer de fonctionnalités. Par exemple, on parse les fichiers XML avec un parser SAX pour limiter la consommation mémoire car il y a des fichiers assez gros (1.3M pour country.xml).

C'est sur ce point qu'on ne se comprend pas. python-sql n'est pas un couche d'abstraction de BD. C'est juste une librairie pour générer des requêtes SQL en les écrivant explicitement avec des objet python plutôt que de manipuler des strings.
python-sql ne connait rien de la BD sur la quelle la requête va être exécutée, d’ailleurs la même requête peut être utilisée pour différentes BD tant qu'on utilise la bonne Flavor de contexte. On se repose entièrement sur les librairies de connexion pour faire leur boulot. S'il y a des manques pour l'une d'entre elle, c'est celle-ci qu'il faut améliorer (pour info, psycopg2 gère les datetime avec fuseau horaire).

Oui, une telle faute de frappe est détectée et lève une exception:

AttributeError: 'Select' object has no attribute 'wehre'

Sauf que par exemple ça ne gère pas les fractions de seconde ni les fuseaux horaires.
Avec une bonne couche d'abstraction, si j'ai un datetime avec un fuseau horaire et des microsecondes et que je le sauve dans une base PostgreSQL, je ne perds pas d'information.

Ça c'est un manquement dans la PEP. Bien que perso, je pense qu'il est préférable de stocker tout en UTC.
De plus, tous les SGDB ne supportent pas les fuseaux horaires par example SQLite.

Ben oui, mais qui écrit / invoque l'adaptateur ? Si c'est ta bibliothèque, alors elle n'ignore plus le type de BD utilisé :-) Si c'est l'utilisateur, ta bibliothèque est sous-optimale par rapport à d'autres solutions.

Je ne trouve pas que ce soit le rôle de la librairie de faire ces choix.
Par exemple, pour Tryton, on a des adaptateurs spécifiques pour les float et Decimal sous PostgreSQL.

C'est pris en charge par la PEP249: http://www.python.org/dev/peps/pep-0249/#type-objects-and-constructors
Et donc il suffit d'utiliser l'expression Literal avec le bon type.
De plus la plupart des librairies de connexion ont des méthodes pour enregistrer des adaptateurs:

• http://initd.org/psycopg/docs/extensions.html#psycopg2.extensions.register_adapter
• http://docs.python.org/2/library/sqlite3.html#sqlite3.register_adapter
• http://mysql-python.sourceforge.net/MySQLdb-1.2.2/public/MySQLdb.converters-module.html

Sauf que c'est pas très performant parce qu'il faut aller lire la définition via le SGDB et plus comme on ne veut dépendre d'aucun SGDB en particulier.

Oui mais avec SQLAlchemy, il faut déclarer la définition des tables avant de pouvoir écrire des requêtes or on ne voulait pas avoir à faire cette déclaration.

Oui mais qui n'utilise que les types de base de Python.

C'est justement un des intérêts de python-sql, c'est qu'il met automatiquement en paramètre les valeurs 'externes' suivant la PEP249. Et comme toute bonne librairie de connexion doit appliquer l'échappement sur les paramètres, il n'y a pas de risque d'injection SQL.
Construire des queries un peu importants manuellement et bien mettre tout en paramètres est vraiment très fastidieux. C'était une des raisons de la création de python-sql.

Il est dommage que les auteurs n'aient pas prévu de formulaire pour soumettre d'autres propositions de logiciels libres.

Voici la page du wiki qui centralise les informations.

Relatorio est toujours bien vivant, la dernière version date de 2 mois bien que la librairie soit plus en mode maintenance pour l'instant.

On est pas sur la même machine.

Et pourquoi pas utiliser l’extension DCC d'irc ?
C'est ce qu'on utilise de temps en temps ici entre collègues.

C'est quand même dommage de sacrifier l'efficacité et l'ergonomie pour éviter le déploiement d'un exécutable.
De plus, je ne vois pas en quoi un navigateur est un environnement habituel, les interfaces graphiques des applications "web" sont tous différents puisque chacune doit redéfinir ses "widgets" de base.

Je suppose que tu parle d'un client Web car le client actuel est un client léger (pas de logique "business" dedans).
Ce n'est clairement pas une priorité puisqu'un tel client n'a que des désavantages par rapport à une application bureau.
Sinon l'idée est de passé à GTK+-3 et d'utiliser le backend broadway ce qui permettrait de ne pas dupliquer le code.

Pour insérer des images avec Relatorio, il faut mettre une expression image: (bitstream, mimetype) dans le champ nom d'une frame. Celle-ci sera remplacée par l'image lors de la génération. Tu peux aussi ajouter la largeur et la hauteur au tuple si tu veux redimensionner l'image à la volée.
Si tu a d'autres problèmes avec Relatorio, tu peux venir poser tes questions sur le channel relatorio

Dernière question : quid du binding PyGtk sous Windows ? Google (ou plutôt Duck Duck Go) ne donnes pas toujours des résultats encourageants. As-tu des retours d'expérience à ce sujet ?

Depuis peu, Gnome propose un installeur "all-in-one" pour pygtk. Ça simplifie grandement l'installation.
http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.24/

>Tout d'abord, il faut remettre les choses dans le context: on a eu de grands désaccords sur la technique avec les deux fondateurs de Tryton, lorsqu'ils étaient employés chez Tiny. Pour ma part, ils étaient complètement à côté de la plaque, pour leur part, ils trouvaient qu'on gérait pas bien les priorités.

On explique ici les points sur le quel on n'était pas d'accord. Ce n'est pas du tout une "attaque" puisqu'on répond au "pourquoi" du fork.

>Suite à cela, ils ont fondé tryton alors qu'ils étaient encore payé par Tiny (ils ont quitté Tiny en février 2008, je vous laisse faire: whois tryton.org), pdt plusieurs mois.

Nous étions tout à fait libre de faire ce qu'on voulait lors de nos temps libre en soirée. De plus réserver un nom de domaine n'est pas fonder une société (en avril).

> *** Suite à une mise en demeure informelle le 16 mars 2009 de la part de Cédric K. de la société B2CK, représentée par le cabinet d'avocats Ramquet, Pricken, Sonnet et Lemmens, ces propos ont été supprimés du site, avec l'accord de leur auteur.*** Je me rappelle aussi que l'un d'eux m'a dit, lorsque je l'ai engagé que son objectif était de créer son entreprise après un an ou deux. C'est chose faite.

Alors là, je n'accepte pas d'être calomnié comme cela en publique. Il faudra que tu arrête de propager ces rumeurs sinon nous serons bien obliger d'y répondre.
Je me rappel bien qu'il y a eu un devis pour une société qui demandait à pouvoir faire exécuter un merging Word à partir du client (différent de la configuration des extensions). Je n'ai jamais fait ce développement, car je n'ai pas eu le temps puisque le devis à été accepté la semaine de mon départ.
Concernant le fait que l'un de nous deux t'aurait dit qu'il comptait créer son entreprise après un an ou deux, a priori aucun de nous deux ne te l'aurait dit à ce moment là. Mais je trouve cela assez étrange d'engager quelqu'un qui t'aurait dit cela. Et si on l'avait dit, ce serait plutôt une preuve d'honnêteté de notre part.

Pour résumer, je n'attaque absolument pas OpenERP, j'ai simplement énuméré les modifications que nous avons apportées dans Tryton. Évidement nous n'avons pas autant de modules que OpenERP, puisque nous les réécrivons "from scratch" et que nous publions les modules que quand nous les considérons complètement utilisable. Dans les mois avenirs, nous publierons de nouveaux modules pour la version 1.0.

Le pourquoi est assez simple Tiny ne voulait pas à l'époque faire le travail de révision de tout le code, ni utiliser des outils pour faciliter les contributions, etc.
Il est vrai que depuis qu'on a démarré, il y a eu des changements du côté de Tiny, je suppose que c'est en réaction à notre projet (vu que certaines améliorations ont été reprises).

1- Non pas directement car le protocol de communication à un peu changé et qu'il y a de nouvelle fonctionnalité au niveau de l'interface qu'il faudrait gérer. Sinon, un client web est en projet mais rien n'est encore définit.

2 - Oui: http://www.tryton.org/services.html

3 - Le code spécifique à psycopg a été regroupé dans le but de pouvoir faciliter l'utilisation d'autre SGBD dans le futur.

4 - Ce n'est pas à l'ordre du jour.

Pour le problème de permanence de l'info. Dans un premier temps, nous avons réglé le problème de la facture en enregistrant le fichier du rapport lors de la validation de celle-ci. Et donc quand on ré-imprime la facture plus tard, on a exactement le même fichier.
De plus nous travaillons pour la version 1.1 à une gestion d'historique des enregistrements, quelques tests ont déjà été réalisés et sont plutôt prometteur.

Pour la licence, OpenERP va passé aussi sous licence GPLv3 ;-)

Tryton a été démarré par deux anciens employés de le société Tiny (dont moi).
Nous étions insatisfait de la manière dont le projet OpenERP (aka TinyERP) était dirigé:
- Manque de vision à long terme
- Pas de volonté de révision des modules existants
- Manque de cohérence entre les modules
- Manque d'intérêt pour la communauté

N'arrivant pas à modifier cela de l'intérieur, nous avons décidé de faire un fork.
Nous avons réécrit les modules de base pour avoir une homogénéité dans le code (pour les développeurs), l'interface (pour les utilisateurs). Nous avons ajouté beaucoup plus d'ergonomie et de contrôle, ce qui fait que Tryton est plus robuste.
(cf http://www.b2ck.com/~ced/Tryton_vs_OpenERP.txt )
Entre autres:
- gestion du curseur dans le client (il se positionne sur le champ en erreur, revient au premier champ du formulaire quand on click sur nouveau),
- amélioration de la vitesse de communication entre le client et le serveur,
- meilleur flux pour les achats (permet de recevoir des commandes groupées du fournisseur),
- gestion de rapport entièrement en ODT (on ne passe plus par un format intermédiaire comme le RML),
- gestion de réapprovisionnement (réellement) JIT,
- gestion de multi-axe analytique,

Sinon certaines améliorations ont été reprises dans OpenERP comme le DnD pour ordonner les lignes d'une liste, la validation des numéro de TVA (http://code.google.com/p/vatnumber/ ).

C'est plus qu'il y avait des problèmes de modélisation dans les modules de base qui ne pouvaient pas être résolu par surcharge.