Cédric Krier a écrit 111 commentaires

Voici l'explication pour Kerberos : http://undeadly.org/cgi?action=article&sid=20140425065910

Soit la suppression est due au fait qu'un meilleur solution existe (généralement en terme de sécurité) comme pour rsh vs ssh.
Soit c'est des logiciels qui n'étaient pas développés par OpenBSD et donc ils sont sorties du système de base en faveur d'un « package ».

La version web du client a aussi bien avancée même si elle n'est pas encore prête pour une utilisation en production.

C'est basé sur CKEditor

Il faut remarqué qu'une partie de cette campagne concerne du développement propriétaire. En effet les themes développés ne seront pas libre (voir la FAQ de la campagne).

https://linuxfr.org/news/sortie-de-tryton-3-2

Aux dernières nouvelles, la politique de migration n'a pas changée, c'est-à-dire qu'elle n'est pas développée de manière ouverte. Mais il semblerait qu'openerp/odoo ne vends plus le service de migration seul, la page des prix ne parlent que d'abonnement au service d'hébergement.

Correction:
* Je n'ai pas dit "ne correspondait pas à ses exigences" mais "ne correspondait pas à mes besoins".
* L'objectif du projet flask-tryton est juste de permettre l'utilisation de Tryton dans une application Flask.

Nereid est monolithique dans le sens où son usage n'est possible que pour les cas d'utilisations restreints déjà prévues par l'auteur (gestion des utilisateurs, de la langue, du multi-société, composition des pages/URLs, etc.).
Pour les modules, en effet il se base sur le mécanisme de Tryton mais je pense personnellement qu'il ne convient pas pour répondre aux demandes variées de création de site web car la modularité ne permet pas de modifier l'architecture.
À propose des modules, le webshop d'après mon analyse est trop simple pour gérer la diversité des cas. Le module de projet est basé sur une simplification de celui de Tryton.

En fait, c'est déjà utilisable. On l'utilise sur notre site web.
Par rapport à Nereid, on profite de tout l'éco-système de Flask qui est bien assez riche. Alors oui, ça reste une boîte à outils et pas un logiciel clés en main mais personnellement ça répond bien mieux à mes besoins.

De plus que ce module utilise MD5 qui n'est plus vraiment considéré comme sûr.

Ça n'a jamais été corrigé et il y a une forte résistance des mainteneurs pour garder cette «fonctionnalité».
Voici le code de la version de développement où le mot de passe est écrit en clair dans la base de données:
https://bazaar.launchpad.net/~openerp/openobject-server/trunk/view/head:/openerp/addons/base/res/res_users.py#L125

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.