Plongez dans mon univers
This is an important step in django_hg build has been reached : authentication — HTTP(S) only — of clone, pushand pullcommands sended by Mercurial is completely handled by django.
There’s two majors workflows:
anonymous_access sets to True), clone et pull are anonymous. push requires an authentication, the user must have the read/write permission for the projet. This schema is often used for open-source projects.anonymous_access sets to False), all commands require to have read/write permission for the projet.In this context, read permission only allow to display project in the browser. I will rename it into web view. This change won’t have any impact on the software, but it will clarify things.
In the next weeks, I will work on the UI, which leads me to see how CSS and images are handled in django reusable apps, like those found in pinax [en]. I also need to complete unavailable functionalities, like diff, branches, …
Afterwards, I think I will add a mini bugtracker, so django_hg will be a simple yet complete tool.
Cette semaine a vu une étape importante dans la conception de django_hg : l’authentification — en HTTP(S) uniquement — des commandes clone, push et pull envoyées par Mercurial est totalement gérée par django.
Elle respecte les deux schémas suivants:
anonymous_access à True), clone et pull sont anonymes. push requiert une authentification, l’utilisateur devant appartenir avoir la permission read/write pour le projet. C’est un schéma que l’on trouve typiquement pour les projet open-source.anonymous_access à False), toutes les commandes requièrent d’avoir la permission read/write pour le projet.Dans ce contexte, la permission read ne donne en fait accès qu’à l’affichage dans le navigateur. Je pense donc la renommer en web view. Ce changement de nom n’aura aucun impact sur le programme, mais cela clarifiera les rôles.
Je vais désormais travailler sur l’interface du projet et il faut que je vois un peu comment sont gérés CSS et images dans les applications réutilisables django, telles que celles que l’on trouve dans pinax [en]. Il faut aussi que je complète les fonctionnalités manquantes (diff, branches, …)
Par la suite, je pense ajouter un mini gestionnaire de bugs, pour en faire un outil simple mais complet.
La semaine passée, j’ai refactorisé l’application de façon à ce que la création des repositories et la gestion des droits se fassent par django [en]. En fait, je me suis largement basé sur django-projectmgr [en] pour le modèle, en modifiant de façon marginale ça et là.
Actuellement la lecture se fait donc selon les droits d’accès et la création d’un nouveau repository est disponible depuis l’admin.
Dans l’ensemble, le refactoring a été simple. La seule difficulté que j’ai rencontrée se situe au niveau de la requête affichant la liste, car je voulais récupérer tous les repositories visibles par un utilisateur en une requête, contrairement à django-projectmgr. Or l’ORM de django ne m’a pas facilité la tâche. J’ai dû utiliser la méthode extra [en], pour un résultat pas très lisible. Pour faire une comparaison avec le monde PHP, je dirais que c’est mieux que Propel [en], mais moins bien que Doctrine [en].
Cette semaine, je compte m’attaquer à permettre le clonage depuis django_hg. J’ai l’impression que cela va être nettement moins simple… car jusqu’à présent, je n’ai pas trouvé grand chose. Le serveur intégré permet le clonage, mais je n’arrive pas trop à savoir où cela se passe. J’ai trouvé un fichier streamclone.py qui semble-t-il permet l’envoi du contenu d’un repository en streaming, mais pour l’instant, je ne suis pas parvenu à en tirer grand chose. La documentation de Mercurial sur HTTP est assez succinte [en].
Si vous voulez récupérer le code, c’est ici [en].
Je viens de mettre à disposition django_hg [en] sur bitbucket [en].
L’objectif de django_hg est de permettre la visualisation dans un projet django [en] d’un repository Mercurial [en].
Si vous connaissez un peu Mercurial, vous savez qu’un serveur web est intégré par défaut. Pourquoi donc refaire ce qui existe déjà ?