Nautilebleu

Dive into my universe

Posts tagged mercurial

0 notes &

django_hg UI

Although I didn’t post any message, I did not stay off these last days. I work on django_hg UI. I take my time, to refine, which is a real pleasure too rare in production. In addition, this leads me to some reflections on the underlying code.

Normally, the code logic should have been based on uses cases. However, given the highly experimental kind of this project (for me), it was quite difficult to conceive any architecture code and the corresponding UI before me diving into the code. In fact, before I start, I was not sure to be able to list the contents of a Mercurial repository in django, and I did not really dream up doing the authentication by django! This project is going much further than I thought, which explains that the code will have to evolve.

In short, I realized that had 3 levels django_hg (between parentheses, the name of the corresponding django_hg):

  • The list of repositories (list);
  • Different views of a repository: Browse (browse), list revisions (Changesets), display a revision (Changeset) and view an overview (Overview)
  • Different views of a file in a repository: the revisions experienced by this file (filelog), display the source code or a preview for images and pdfs (filerev), diff between 2 revisions (filediff, very far to be operational yet)

From the viewpoint of the interface, these three types of files use different templates. But I’m currently thinking that I should refactor my code so that it has only 3 views, with cases for some of them.

This does not however going to be right away, because I would move the graphic considerations. Speaking about that, what is the good practice to distribute graphics (images, css, …) for a reusable application?

Filed under django django_hg mercurial

0 notes &

Interface de django_hg

Bien que je n’ai pas posté de message, je ne suis pas resté inactif ses derniers jours. Je travaille sur l’interface. Je prend mon temps, pour peaufiner, ce qui est un véritable plaisir, trop rare en production. En outre, cela m’amène à certaines réflexions sur le code sous-jacent.

Normalement, la logique du code aurait dû être issue des uses-cases. Cependant, étant donné la nature très expérimentale (pour moi) de ce projet, il était assez difficile de concevoir toute l’architecture du code et l’interface correspondante avant de me plonger dans le code. En fait, avant de commencer, je n’étais pas sûr d’arriver à lister le contenu d’un repository Mercurial dans django, et je n’imaginais pas vraiment faire l’authentification par django ! Ce projet est donc allé beaucoup plus loin que je ne le pensais, ce qui explique que le code soit amené à évoluer.

Bref, je me suis rendu compte que django_hg avait 3 niveaux (entre parenthèses, le nom de la vue correspondante dans django_hg) :

  • la liste des repositories (list) ;
  • différentes vues d’un repository : parcourir (browse), lister les révisions (changesets), afficher une révision (changeset) et afficher un aperçu général (overview)
  • différentes vues d’un fichier au sein d’un repository: les révisions qu’a connu ce fichier (filelog), afficher du code source ou d’un aperçu pour les images et les pdfs (filerev), les différences entre 2 révisions (filediff, très loin encore d’être opérationnel)

Du point de vue de l’interface, ces trois types de fichiers utilisent des templates différents. Mais je suis en train de me dire que je pourrais refactoriser mon code pour qu’il n’ait que 3 vues, avec pour certains, plusieurs cas de figure.

Cela ne vas toutefois pas être pour tout de suite, car je voudrais avancer sur les considérations graphiques avant. À ce propos, quelles sont les bonnes pratiques pour distribuer des ressources graphiques (images, css, …) pour une application réutilisable ?

Filed under django django_hg mercurial

0 notes &

django_hg : authentication throught django is OK

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:

  • For public projects (with 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.
  • For private 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.

Filed under django django_hg hg mercurial authentication

0 notes &

django_hg : l’authentification au travers de django est OK

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:

  • Pour les projets publics (avec 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.
  • Pour les projets privés (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.

Filed under django hg mercurial authentification

0 notes &

django_hg sait cloner

J’ai profité du pont pour travailler sur l’un des points qui me semblait le plus critique dans django_hg, la gestion par django des requêtes HTTP utilisées pour cloner (et pour puller.)

Je dois dire que cela s’est très bien passé, bien plus que je ne l’aurai pensé, grâce notamment à l’aide de la mailing-list (et en particulier de Dirkjan Ochtman [en] et Benoît Boussicot [en].) En fait, ce qui m’a le plus retenu, c’est que je m’attendais tellement à galérer que j’ai fait des erreurs bêtes et tout développeur sait bien que ce sont les erreurs les plus évidentes qui sont les plus difficiles à corriger !

Faire traiter par django les requêtes d’un clone est donc très simple:

# views.py
def commands(request, name): 
    """ handles the commands sended by an hg client (clone, pull, push) 
    ``name`` 
        the name of the repository 
    """
    from mercurial import hg, ui 
    from mercurial.hgweb.request import wsgirequest 
    from mercurial.hgweb import protocol 

    cmds = ['between', 'branches', 'capabilities', 'changegroupsubset', 'heads'] 
    r = hg.repository(ui.ui(), name) 
    req = wsgirequest(request.META, None) 

    if request.GET.get('cmd') in cmds: 
        resp = protocol.__getattribute__(request.GET.get('cmd'))(r, req) 

    return HttpResponse(resp, protocol.HGTYPE)

Les imports correspondent aux différents objets de Mercurial. On note en particulier que les requêtes sont des objets wsgirequest. Cela tombe bien, django aussi, à ceci prêt que la request django engloble les données nécessaires à la création d’une requête wsgi dans le dictionnaire request.META.)

La liste des commandes disponibles est décrite dans cmds. Il suffit de créer en plus un objet repository r et après avoir vérifié que la commande est bien une des commandes attendues par l’objet protocol qui gère toutes les étapes [en] d’un clone, on obtient un flux qu’il suffit de retourner à Mercurial avec le bon type MIME, avec l’objet HttpResponse de django, dont l’inclusion se fait au niveau du module.

Simplissime, non ? Vous pouvez voir le code en situation sur bitbucket [en].

Ce code ne gère pas l’authentification. Je compte me pencher sur la question cette semaine, même si auparavant, je voudrais me pencher un peu sur ce blog qui est un peu en vrac depuis que Free, sur lequel j’héberge encore les images, est en carafe…

Filed under django django_hg python mercurial

0 notes &

Progression de django_hg

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].

Filed under django mercurial hg

0 notes &

django_hg

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à ?

  • Pour apprendre Python !
  • Pour apprendre django !!
  • Pour apprendre Mercurial !!! Sur ces points, je trouve que ça se passe plutôt bien, dans l’ensemble, pas trop de galère, à part la mise en place des doctests sur les templatetags.
  • et aussi parce que je pense qu’il est plus facile d’adapter des templates django que ceux de Mercurial,
  • parce qu’à terme je souhaite ajouter des fonctions telles que l’intégration de l’authentification django. Cela va d’ailleurs être mon prochain travail, en me basant sur django-projectmgr [en].

Filed under django mercurial hg python