Journal Chronokiwi sort en version d3b63be4cb

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
6
1
nov.
2011

Cher Nal,

Je t'écris pour te faire part des évolutions de mon projet Chronokiwi, le wiki spécialisé dans la saisie et la présentation d'évènements et de chronologies écrit avec Django sous licence BSD.

La dernière version dont je t'ai parlé était assez basique, mais aujourd'hui commence vraiment à prendre forme grâce aux nouveautés suivantes:

  • liens entre les pages des évènements et les chronologies via une extension de la syntaxe Markdown.
  • flux RSS.
  • export de chronologies sous forme d'un graphe (via Graphviz)
  • géolocalisation des évènements via GeoDjango et Openlayers.

La prochaine fonctionnalité importante que j'aimerais implémenter est une "timeline" visuelle intégrée avec une carte afin de pouvoir, par exemple, visualiser de façon interactive l'évolution d'une invasion.

J'aimerais aussi améliorer la partie cartographique, mais je suis assez limité par les versions de Django et GeoDjango proposées par ma distribution. Apparemment les développeurs Python modernes se font des "virtualenv" et des "pip" pour résoudre ce genre problème, mais je n'ai pas eu le temps d'explorer le sujet.

Page du projet
Demo

  • # Les développeurs Python modernes...

    Posté par  . Évalué à 8.

    ...ne se soucient plus de la pérennité de leur application en abusant de dépendances à des projets pas forcément mature.

    Le fichier de « requirements » de certains projets fait vraiment peur (avec parfois une dizaine dépendance sur des dépôts GitHub d'autres petits projets). C'est vite un cauchemar pour les administrateurs qui auraient des velléités d'installation de pareil logiciel. Je ne parle pas des empaqueteurs.

    Je me demande si on n'a pas trop simplifié la vie des développeurs :)

    Tout ça pour dire que c'est pas mal aussi de ne pas courir de suite après les dernières versions des bibliothèques que l'on utilise.

    Un développeur Python

    • [^] # Re: Les développeurs Python modernes...

      Posté par  . Évalué à 1.

      Tout dépend du contexte, parfois ça aussi du bon d'avoir une version récente qui corrige les bugs ou rajoute des fonctionnalités dont tu as besoin.
      Par exemple, la version de xlrd dans Debian Lenny a des problèmes avec certains fichiers XLS, j'étais content d'avoir la version qui fonctionne grâce à virtualenv.

      Et justement, virtualenv évite de "pourrir" ce qui est installé sur le serveur.

      Ça rentre en contradiction de la philosophie de la plupart des distributions Linux, où il n'y a qu'une version de librairie partagée par tous, pour simplifier les mises à jours et éviter la duplication, mais dans les faits, surtout pour du développement custom, il faut aussi être pragmatique.

      En effet, quel est l'intérêt que le développeur redéveloppe dans son application quelque chose qui existe déjà dans la nouvelle version de la librairie ?

      • [^] # Re: Les développeurs Python modernes...

        Posté par  (site web personnel) . Évalué à 2.

        Je ne comprends pas trop cet histoire de virtualenv. Dans d'autres langages, soit on utilise les libs du systèmes, soit on embarque ses propres versions avec le programme.

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Les développeurs Python modernes...

          Posté par  . Évalué à 1.

          Virtualenv, ça correspond à embarquer ces propres versions avec le programme, mais avec un système de packages comme les distributions Linux pour gérer facilement les dépendances et les mises à jour. Ce n'est pas obligatoire, mais ça fait gagner du temps, surtout pour les eggs Python avec du code C.

      • [^] # Re: Les développeurs Python modernes...

        Posté par  . Évalué à 2.

        Tu exagères pour les librairies.
        Il y a une version principale de librairie mais rien n'empêche de viser une autre version si besoin est. Ça fait belle lurette que la notation unix .so.X.Y est utilisée.

        Pour ce qui d'avoir plusieurs versions d'une même librairie sur un système, j'ai peine à croire que la notion de slot (qui est le nom désignant ce mécanisme sous Gentoo) soit si marginal. Dire que ce n'est pas le but, oui, insinuer que rien n'est fait pour, non.

        • [^] # Re: Les développeurs Python modernes...

          Posté par  . Évalué à 1.

          Oui, en théorie, non, en pratique dans toutes les distributions Linux que je connais, il faut que ça soit explicitement défini, par exemple python2 et python3, tu ne peux pas installer en même temps les versions que tu veux, même avec les slots, il faut que ça soit explicitement défini dans les ebuilds de mes souvenirs de Gentoo.

          • [^] # Re: Les développeurs Python modernes...

            Posté par  . Évalué à 1.

            Tu as en effet un ebuild par version, et tu peux installer autant de version que tu veux : (ici un python2 et un python3)

            ~
[_](51314:20fredd@p-v-fheulin)> eix -ce python

[I] dev-lang/python
     Available versions:  
        (2.4)       2.4.6
        (2.5)       2.5.4-r4
        (2.6)       2.6.6-r2 ~2.6.7-r2
        (2.7)       2.7.1-r1 ~2.7.2-r2 ~2.7.2-r3
        (3.1)       3.1.3-r1 ~3.1.4-r2 ~3.1.4-r3
        (3.2)       ~3.2-r2 ~3.2.2
  {-berkdb bootstrap build +cxx doc elibc_uclibc examples gdbm ipv6 +ncurses 
   +readline sqlite +ssl +threads tk +wide-unicode wininst +xml}
  
  Installed versions:

  2.7.1-r1(2.7)(13:12:50 01/06/2011)
  (gdbm ipv6 ncurses readline sqlite ssl threads wide-unicode xml -berkdb -build
   -doc -elibc_uclibc -examples -tk -wininst)
  
  3.1.3-r1(3.1)(12:55:08 04/04/2011)
  (gdbm ipv6 ncurses readline sqlite ssl threads wide-unicode xml -build -doc
   -elibc_uclibc -examples -tk -wininst)
   
     Homepage:            http://www.python.org/
     Description:         Python is an interpreted, interactive,
                          object-oriented programming language.

            Ensuite chaque package peut restreindre sa compatibilité avec une version de python ou une autre. (ce qui est précisé dans les ebuild)

            Enfin il y a une version de python par défaut :

            ~
[_](50214:34fredd@p-v-fheulin)> eselect python list
Available Python interpreters:
  [1]   python2.7 *
  [2]   python3.1

            Ici la 2.7.
            On peut la changer temporairement pour compiler des packages avec une version particulière de python et revenir à la version initiale pour l'install des autres packages.

            • [^] # Re: Les développeurs Python modernes...

              Posté par  . Évalué à 1.

              C'est ce que je dit, il faut que ça soit prévu dans l'ebuild, ce n'est pas vrai pour tous les ebuilds.

              Par exemple, si je veux la 2.6.6-r2 et la 2.6.7-r2, ce n'est pas possible car s'est dans le même slot. Je ne peux avoir qu'une version dans mon slot.

              Et encore, c'est parce que Gentoo est très souple, la plupart des distributions n'ont pas un système aussi fin.

              • [^] # Re: Les développeurs Python modernes...

                Posté par  . Évalué à 1.

                Oui à ce niveau de version, c'est du correctif sans de changement d'apis donc ils ont considérés qu'une version à la fois était logique (et suffisant).

                Sinon oui gentoo est très souple à ce niveau, par nécessité pour la compilation des packages en partie d'ailleurs.
                Par exemple pour automake, j'ai trois slots d'installé ! :

                ~
[rls](50417:17fredd@p-v-fheulin)> eix -ce automake
[I] sys-devel/automake
     Available versions:  
        (1.4)   1.4_p6-r1
        (1.5)   1.5-r1
        (1.6)   1.6.3-r1
        (1.7)   1.7.9-r2
        (1.8)   1.8.5-r4
        (1.9)   1.9.6-r3
        (1.10)  1.10.3
        (1.11)  1.11.1 ~1.11.1-r1
        (9999)  **9999
     Installed versions:
   1.9.6-r3(1.9)(11:03:17 29/04/2010)
   1.10.3(1.10)(10:45:45 25/02/2010)
   1.11.1(1.11)(10:45:55 25/02/2010)

        • [^] # Re: Les développeurs Python modernes...

          Posté par  . Évalué à 3.

          Je pense que l'idée c'est surtout d'avoir un environnement de développement cloisonné du système pour pouvoir facilement le reproduire sur n'importe quel machine que ce soit pour les développeurs, l'intégration continue ou pour la production.

          Ça devrait permettre (je n'ai jamais vraiment essayé) de facilement développer sur Fedora, faire de l'IC sur Gentoo et mettre en prod sur Debian.

          Pour un projet libre qui est susceptible d'avoir des contributeur sur différents OS ça me semble être une bonne idée.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Les développeurs Python modernes...

      Posté par  . Évalué à 3.

      Je te rassure, c'est pareil chez les devs RoR. Ce qui est marrant, c'est que ce n'est pas comme ça chez les devs Python et Ruby qui ne font pas du web

      • [^] # Re: Les développeurs Python modernes...

        Posté par  . Évalué à 2.

        Pour rajouter une couche, on a l'impression qu'ils font comme sur facebook : ils mettent leur cervelle de côté :)
        "social coding"... et vas-y que je suis (de "suivre") n'importe quoi, que je forke en modifiant tout à mon style sans en discuter et que j'envoie des pulls requests à tout va, comme 10 autres de mes congénères qui ont fait pareil, que je like un commit en lâchant un com' sur une ligne de code qui est vraiment trop lol.

      • [^] # Re: Les développeurs Python modernes...

        Posté par  . Évalué à 1.

        Les technos dans le Web bougent plus que les sockets UNIX, en effet ;-)

        tout dépend ce que tu fais avec Python et Ruby, je fais pas mal de choses qui n'ont rien à voir avec du Web, pourtant, ça m'arrive d'avoir besoin d'une lib qui n'est pas dans le système. Mais ce qui est au niveau du système est souvent plus figé et abouti que ce qu'il y a pour le Web, question d'ancienneté des technologies.

  • # À propos de pip et virtualenv

    Posté par  (Mastodon) . Évalué à 2.

    Salut,

    Je suis un développeur d'applications django, et j'utilise les environnements virtualenv avec pip au quotidien, et c'est vachement bien... et assez facile à utiliser.
    Tu trouves d'ailleurs plein de tutos sur Internet pour ce sujet.

    L'interêt principal pour moi est de faire cohabiter plusieurs projets django sur le même serveur, sans me prendre la tête et sans me soucier des versions de libs.
    Bon courage pour ton projet, et bonnes timelines !

    Juste un conseil : use et abuse des 'class-based views' (django 1.3.+), elle te simpolifient réellement la vie et surtout la lisibilité du code.

    frague

    • [^] # Re: À propos de pip et virtualenv

      Posté par  . Évalué à 4.

      Juste pour troller :

      L'interêt principal pour moi est de faire cohabiter plusieurs projets django sur le même serveur, sans me prendre la tête et sans me soucier des versions de libs.

      Java le fait depuis 10 ans :)

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: À propos de pip et virtualenv

        Posté par  . Évalué à 9.

        Java le fait depuis 10 ans :)

        Mais les serveurs capables de faire tourner ça ne sortiront que dans 5 ans !

        • [^] # Re: À propos de pip et virtualenv

          Posté par  . Évalué à 5.

          C'est faux dans 5 ans il y auras 2 versions supplémentaires de Java EE qui seront sorti pour garantir que ça n'arrive pas.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: À propos de pip et virtualenv

      Posté par  . Évalué à 4.

      sans me soucier des versions de libs

      Je crois que c'est justement le reproche.

      Ignorer complètement ce problème, c'est complexifier de beaucoup l'empaquettage, puis l'intégration dans une distribution, ce qui freine d'autant plus l'adoption du logiciel, indépendamment de ses qualités.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Un truc de communiste ?

    Posté par  (site web personnel) . Évalué à 4.

    C'est un truc de communiste ce logiciel ? Je demande cela parce que le lien vers le flux RSS dans le site de démo est "flURSS" :)

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Un truc de communiste ?

      Posté par  . Évalué à 4.

      Plutôt un truc de flowmmuniste non ?

    • [^] # Re: Un truc de communiste ?

      Posté par  (site web personnel) . Évalué à 2.

      Cette blague a été lâchement volé à CanardPC.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Un truc de communiste ?

        Posté par  (site web personnel) . Évalué à 2.

        Je devrais postuler chez eux alors car je ne lis pas ce Canard même si j'en ai entendu beaucoup de bien.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: Un truc de communiste ?

        Posté par  . Évalué à 2.

        PAN !

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.