Journal upt: l'outil parfait pour empaqueter TapTempo

Sommaire

• Obtenir TapTempo depuis une archive de paquets spécifique à un langage
• Obtenir TapTempo /via/ son OS
• upt : une conception modulaire
• Exemples
• Travaux futurs
• Liens

Bonjour tout le monde,

Je vais faire (éhontément) un peu de pub pour mon dernier projet, upt : the Universal Packaging Tool, ou encore "l'outil d'empaquetage universel", comme on dit en France, de Bretagne en Provence.

Obtenir TapTempo depuis une archive de paquets spécifique à un langage

La communauté récemment formée autour de TapTempo a la possibilité d'utiliser diverses implémentations du logiciel, écrites dans de nombreux langages différents. Toutes ces versions de TapTempo seront sans doute bientôt disponibles sur des archives de paquets telles que PyPI, CPAN ou encore RubyGems. Il sera ensuite possible d'installer TapTempo grâce aux commandes suivantes :

# pip3 install taptempo
# cpan install App::TapTempo
# gem install taptempo

Obtenir TapTempo /via/ son OS

De nombreux utilisateurs souhaiteraient toutefois installer TapTempo grâce au gestionnaire de paquets de leur distribution. Ce sera sans doute chose aisée, puisqu'à n'en pas douter, des hordes de mainteneurs vont s'efforcer d'empaqueter TapTempo dans les jours qui viennent. Il sera ensuite possible de taper une des commandes suivantes dans son terminal :

# apt install python3-taptempo
# dnf install python3-taptempo
# guix package -i python-taptempo

Créer un paquet pour Debian, Fedora ou encore Guix à la main serait un peu fastidieux. Il est donc sans doute probable que les empaqueteurs s'aideront de scripts permettant de convertir un paquet Python/Perl/Ruby/… en un paquet Debian/Fedora/Guix/… Il existe d'ailleurs de nombreux scripts de ce genre :

• pypi2deb;
• gem2deb;
• npm2rpm;
• PortGen : construction d'un paquet PyPI/Perl/Ruby pour OpenBSD;
• url2pkg: construction automatique d'un Makefile pour pkgsrc;
• guix import : création d'un paquet Guix depuis diverses archives.

Toutefois, cette multiplication d'outils pose plusieurs problèmes:

• leur interface n'est pas unifiée : chaque outil a sa propre syntaxe, ses propres options, et il est peu évident de passer de l'un à l'autre;
• leur comportement n'est pas unifié : certains outils vont créer des fichiers quand d'autres se contenteront d'écrire sur la sortie standard; certains lanceront la compilation et pas d'autres; etc.
• tous les outils qui permettent de ré-empaqueter un paquet disponible sur PyPI réimplémentent le même type de code; tous les outils qui génèrent un paquet Debian (par exemple) réimplémentent du code similaire. On a donc un beau cas du syndrôme de "pas inventé ici". Certains outils (guix import, PortGen) permettent cependant de factoriser une partie du code.

upt : une conception modulaire

En se penchant bien sur le problème, on peut voir que l'on cherche à "traduire" la représentation d'un paquet en amont (celle disponible sur PyPI/CPAN/RubyGems, etc.) en une sa représentation en aval (celle disponible dans nos distributions).

C'est un problème finalement classique en informatique. Deux exemples :

• un compilateur tel que GCC sait compiler de N langages vers P architectures, mais il n'implémente pas N*P compilateurs : il fournit N frontends qui convertissent le code en entrée vers une représentation interne, et P backends, qui convertissent cette représentation interne en code valide pour chaque architecture;
• pandoc sait convertir des documents d'un langage de balisage à un autre : pour ce faire, il implémente des lecteurs et des écrivains, qui sont rendus compatibles en partageant une représentation interne des documents.

L'outil que j'ai développé récemment, upt (the Universal Packaging Tool) fonctionne de façon similaire, en implémentant deux concepts :

• des frontends transforment un paquet présent sur une archive telle que PyPI/CPAN/RubyGems en une réprésentation interne à upt;
• des backends transforment cette représentation interne en une définition de paquet (presque) valide pour un gestionnaire de paquets traditionnel.

Un peu d'art ASCII vaut mieux qu'un long journal:

   Archive   |   Frontends   |    upt   |     Backends     |  Définitions       
   en amont  |      upt      |          |       upt        |   de paquet        
             |               |          |                  |                    
  +------+   |  +----------+ |  +-----+ |  +-------------+ |  +----------+   
  | PyPI |---|->| upt-pypi |-|->|     |-|->|  upt-guix   |-|->| Guix pkg |   
  +------+   |  +----------+ |  |     | |  +-------------+ |  +----------+   
             |               |  | upt | |                  |                    
  +------+   |  +----------+ |  |     | |  +-------------+ |  +----------+   
  | CPAN |---|->| upt-cpan |-|->|     |-|->| upt-openbsd |-|->| Makefile |   
  +------+   |  +----------+ |  +-----+ |  +-------------+ |  +----------+   

Le "cœur" du projet est "upt", qui permet de faire travailler ensemble les frontends et les backends. On peut ainsi générer un paquet pour GNU Guix qu'il soit distribué sur CPAN ou sur PyPI. De même, on peut facilement distribuer python-taptempo sur GNU Guix et OpenBSD en utilisant upt-pypi, upt-openbsd et upt-guix.

Exemples

Voyons comment utiliser upt. Il faut tout d'abord l'installer (attention, il ne fonctionne qu'avec Python 3) avec l'une des commandes suivantes :

$ pip3 install upt
$ pip3 install upt[frontends] # upt et tous ses frontends
$ pip3 install upt[backends] # upt et tous ses backends
$ pip3 install upt[frontends,backends] # upt et tous ses frontends/backends

Nous pouvons ensuite lister les frontends et backends disponibles :

$ upt list-frontends
rubygems
pypi
cpan

$ upt list-backends
openbsd
guix

Essayons maintenant d'empaqueter requests_mock pour GNU Guix :

$ upt package -f pypi -b guix requests_mock
(define-public python-requests_mock
  (package
    (name "python-requests_mock")
    (version "1.4.0")
    (source (origin
              (method url-fetch)
              (uri (pypi-uri "requests_mock" version))
              (sha256
               (base32
                "XXX")))))
    (build-system python-build-system)
    (inputs
     `())
    (native-inputs
     `(("python-fixtures" ,python-fixtures)
       ("python-mock" ,python-mock)
       ("python-sphinx" ,python-sphinx)
       ("python-testrepository" ,python-testrepository)
       ("python-testtools" ,python-testtools)))
    (propagated-inputs
     `(("python-requests" ,python-requests)
       ("python-six" ,python-six)))
    (home-page "https://requests-mock.readthedocs.org/")
    (synopsis "Mock out responses from the requests package")
    (description "XXX")
    (license license:asl2.0)))

(define-public python2-requests_mock
  (package-with-python2 python-requests_mock))

Et pour OpenBSD :

$ upt package -f pypi -b openbsd requests_mock
COMMENT =       mock out responses from the requests package

MODPY_EGG_VERSION = 1.4.0
DISTNAME =      requests_mock-${MODPY_EGG_VERSION}
PKGNAME =       py-requests_mock-${MODPY_EGG_VERSION}

CATEGORIES =        XXX

HOMEPAGE =      https://requests-mock.readthedocs.org/

MAINTAINER =        XXX XXX <xxx@xxx.xxx>

# Apache-2.0
PERMIT_PACKAGE_CDROM =  Yes

MODULES =       lang/python
MODPY_SETUPTOOLS =  Yes # Probably
MODPY_PI =      Yes

RUN_DEPENDS =       xxx/py-requests${MODPY_FLAVOR} \
            xxx/py-six${MODPY_FLAVOR}
TEST_DEPENDS =      xxx/py-fixtures${MODPY_FLAVOR} \
            xxx/py-mock${MODPY_FLAVOR} \
            xxx/py-sphinx${MODPY_FLAVOR} \
            xxx/py-testrepository${MODPY_FLAVOR} \
            xxx/py-testtools${MODPY_FLAVOR}


.include <bsd.port.mk>

On voit que les définitions générées ne sont pas utilisables en l'état, mais 80% du travail de l'empaqueteur est effectué automatiquement.

Nous avons résolu nos problèmes :
* la CLI est désormais unifiée;
* le comportement est similaire d'un backend à l'autre;
* on n'implémente une fois seulement la récupération des informations concernant un paquet en amont; de même, on implémente qu'une seule fois la génération d'un paquet en aval.

Le dernier point semble trop beau pour être vrai. En effet, le langage utilisé influe très légèrement sur le contenu du paquet en aval. Les backends ne sont donc pas tout à fait "génériques"; toutefois, le code spécifique à un langage est en général très court.

Travaux futurs

Pour l'instant, trois frontends et deux backends sont disponibles. Si upt vous intéresse, je vous invite à le tester et à :

• participer au développement : le projet utilise framagit, mais vous pouvez vous y connecter grâce à vos identifiants Github, youhou ! L'équipe d'upt est très sympathique, bien que principalement constituée de ma personne;
• ajouter votre propre frontend ou backend : même pas besoin de m'envoyer une requête de tirage (une "pull request" comme on dit dans le reste du monde), puisqu'upt utilise les points d'entrée de setuptools. Tous les modules peuvent donc être développés dans leur propre dépôt.

Et si le projet ne vous intéresse pas assez pour y contribuer, bah j'f'rai tout moi-même, et pis tant pis, je s'rai tout triste.

Liens

• upt
• upt-cpan
• upt-pypi
• upt-rubygems
• upt-guix
• upt-openbsd