CEAN 2.0

Posté par (page perso) . Édité par Christophe ROMAIN, Xavier Claude, Florent Zara, tuiu pol et NeoX. Modéré par Malicia. Licence CC by-sa
Tags :
20
9
jan.
2012
Communauté

CEAN est l'acronyme de Comprehensive Erlang Archive Network, en d'autres termes l'alter ego pour le langage Erlang de CPAN (Comprehensive Perl Archive Network) pour le langage Perl. Le dépôt centralisé propose également des installateurs d'une version minimaliste du langage. Après trois ans d'un apparent long silence, c'est la version 2.0 que Christophe Romain publie.

Plus que l'installation de binaires avec les dépendances, CEAN 2.0 fournit un framework de développement, construction (build), et paquetage (packaging). Il repose sur zsh, ce qui le rend compatible sur tous les systèmes POSIX.

CEAN 2.0 est disponible :

  • Sous forme d'archive et d'installateur,
  • Pour Erlang R12B-5, R13B04, R14B04, et R15B,
  • Pour de multiples OS et architectures : Linux (ARMv5 et v7, Hitachi SH4, Intel 32 et 64 bits, MIPS, MIPSEL, PowerPC, SPARC 32 et 64 bits), Mac OS X (Intel 32 et 64 bits), NetBSD (Intel 32 bits), et Windows.

Quelques détails et une petite interview de Christophe Romain en seconde partie de cet article.

Les fonctionnalités de CEAN 2.0 sont, entre autres :

  • Commandes shell Unix et Erlang
  • Le framework de construction et paquetage est opensource, sous licence GPL
  • Possibilité de générer des paquets et installateurs indépendants
  • Fonctionne en environnement cluster : il est possible de synchroniser l'installation de Erlang/CEAN sur plusieurs hôtes en une seule commande
  • Possibilité d'avoir autant de versions de Erlang installées que vous voulez sur la même machine
  • Générateur de dépendances de paquets amélioré

Petite interview de Christophe Romain...

Pourquoi tant de temps depuis la dernière version ?
La précédente version s'appuyait sur un ensemble de scripts anciens, qui ont été modifiés et enrichis pendant plus de 6 ans, et dont le but initial n'était pas la génération d'un tel dépôt de paquets binaire.
Ces scripts étaient compliqués, et exigeaient plusieurs heures de travail à chaque nouvelle version d'Erlang. Je ne disposais plus du temps nécessaire pour le maintenir.
Ainsi, je me suis lancé au printemps 2010 dans une réécriture totale des scripts CEAN, en commençant par la définition d'un framework extensible, simple et robuste. Ce framework, écris en ZSH, a ensuite été validé tout au long de l'année 2011.
Cela représente environ 1500 lignes de ZSH, un mois de spécification, autant d'écriture, et plusieurs mois de tests/validation en tâche de fond.

Y a-t-il une roadmap ?
Non. Je travaille sur ce produit ponctuellement seulement.
Néanmoins, l'objectif est d'être à présent très réactif aux sorties des versions Erlang. Donc même si le framework avance doucement, les dépôts binaires devraient quant à eux être régulièrement à jour.
L'outil de gestion de projet et le code sont disponibles, l'appel à contributions est lancé !
La roadmap éventuelle sera définie selon l'usage, les retours et les contributions.

Pourquoi avoir choisi le modèle CPAN ? Pourquoi pas un paquetage deb ou rpm (ou autre) ? Quelles sont les différences ?
Il y a eu de longues discussions à ce sujet, et ce depuis 2005.
Maintenir un ensemble de paquets est déjà une tâche lourde. Erlang fonctionne sous Linux comme sous Windows, et nous devions proposer un accès simple quelque soit le système hôte. C'est pour cette raison que nous avons pris le modèle CPAN, qui a fait ses preuves. Ce système fonctionne dès que vous avez une machine virtuelle Erlang entre les mains, et sans les droits administrateurs, ce qui est majoritairement le cas.
Néanmoins, il reste peu à faire pour générer dynamiquement des paquets .deb et .rpm à partir du dépôt CEAN. Si certains sont intéressés, qu'ils se fassent connaitre et nous pourrons avancer sur ce point.

Vous servez-vous de CEAN pour les livraisons de ejabberd ?
Oui, ProcessOne utilise sur CEAN pour générer des installateurs ejabberd.

  • # Pas tout à fait un CPAN

    Posté par (page perso) . Évalué à 4.

    C'est une remarque que j'avais déjà faites pour OCaml, le truc très important dans le CPAN, c'est que les tar.gz sont dans le CPAN ! C'est pas juste un annuaire. La centralisation des sources assure aux utilisateurs du CPAN d'avoir toutes les versions d'un paquetage et les sources quoiqu'il advienne au projet amont. Ceci dis, on ne développe pas sous CPAN mais ailleurs et on upload sur le CPAN ses distributions, pas exemple avec dzil.

    http://search.cpan.org/~rjbs/Dist-Zilla-4.300006/

    Sauf erreur de ma part, j'ai pas vu de source dans le CEAN.

    On est donc pour moi encore très loin d'un vrai CPAN...

    • [^] # Re: Pas tout à fait un CPAN

      Posté par (page perso) . Évalué à 1.

      si, le contenu des archives .epkg contiennent les binaires, le bytecode, les includes et les sources. par defaut, la commande cean:install deploi que les binaires et le bytecode, mais il est prevu d'ajouter une option pour choisir d'extraire ou pas les sources, présente dans les fichiers .epkg

      • [^] # Re: Pas tout à fait un CPAN

        Posté par (page perso) . Évalué à 2.

        Je n'ai pas du avoir de chance car parmi la dizaine de paquet testé, je n'en ai pas trouvé un seul qui ne pointe pas vers un lien externe au CEAN. As tu un exemple ?

        • [^] # Re: Pas tout à fait un CPAN

          Posté par (page perso) . Évalué à 1.

          exemple:
          $ tar tf mnesia-4.5.epkg
          mnesia-4.5.doc.zip
          mnesia-4.5.src.zip <-- les sources sont là
          mnesia-4.5.ez
          $ tar tf yaws-1.91.epkg
          yaws-1.91.doc.zip
          yaws-1.91.priv.zip
          yaws-1.91.src.zip <-- et ici
          yaws-1.91.ez

          ensuite, chaque packet à son tar.gz de sources associé, archive générée sur le serveur cean, ne redirigeant pas vers la source.
          exemple:
          http://cean.process-one.net/repos/src/yaws/yaws-1.91.tgz

          enfin, si on transforme une installation CEAN en espace de travail avec le framework de build (utiliser la commande bin/initworkdir pour cela), on recupère un depot git local de toutes les sources des packets construits.

  • # Rendons à César...

    Posté par . Évalué à 4.

    Je tiens à rappeler que CPAN n'est pas le premier du genre. C'est bien le CTAN (Comprehensive TeX Archive Network) qui le premier a ouvert la voie (1992). CPAN a suivi en 1995.

    • [^] # Re: Rendons à César...

      Posté par (page perso) . Évalué à 3.

      Il faut dire que TeX est un monstre du logiciel libre, bien avant la FSF (1978)... d'ailleurs cela se voit dans sa licence d'une clarté peu claire ;-)

      Cependant, le CPAN a rapidement dépassé son mentor pour des raisons assez logique (début du web, langage de script...). Les autres langages "libre" ont suivis que très très lentement le mouvement.

      Le couple CTAN/CPAN restera donc dans l'histoire comme les premiers, loin devant les autres. De plus, bien que le CTAN soit plus vieux, les deux sont assez indissociables. Perl/CPAN est alors à ma connaissance le premier langage communautaire.

      Ceci dis, l'étape suivante me semble l'intégration d'un équivalent de github au coeur même des C*AN...

      • [^] # Re: Rendons à César...

        Posté par (page perso) . Évalué à 2. Dernière modification le 10/01/12 à 22:26.

        Il y a déjà des efforts en ce sens. Ainsi "oh-my-vim" permet de faire une recherche et une installation directement parmi les projets marqués vimL de github.

        • [^] # Re: Rendons à César...

          Posté par (page perso) . Évalué à 3.

          github ne sera JAMAIS un C*AN !

          github est un truc pratique mais temporaire... Tu ne vas pas baser toutes les bibliothèques libres de ton langage sur une plateforme que tu ne maîtrises pas ! On a vu à l'automne les soucis avec berlioz (si mes souvenir sont bon...).

  • # Commentaire supprimé

    Posté par . Évalué à -1. Dernière modification le 11/01/12 à 08:32.

    Ce commentaire a été supprimé par l'équipe de modération.

Suivre le flux des commentaires

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