Journal py2deb : fabriquer des debs facilement ...

Posté par  (site web personnel) .
Étiquettes : aucune
0
4
jan.
2008
Il y a t il des spécialistes "debian / deb" dans la salle ? (je pense que oui, sinon je ne posterai pas ici)

Je ne suis pas un spécialiste deb, je tourne sous ubuntu, mais je galère toujours un peu pour livrer mes créations. J'ai donc créer un module python permettant d'automatiser la tâche au maximum.
Le résultat est plutôt probant : ça génère des debs, qui semblent bien fait, et qui en plus : s'installent ;-)

En fait, je me suis vachement inspiré de ce tutorial :
http://wiki.showmedo.com/index.php?title=LinuxJensMakingDeb

En gros, pydeb, consitue les fichiers debian/* automatiquement, et utilise les outils de dpkg-dev, à savoir dpkg-buildpackage en fakeroot pour consituer un paquet deb (et accessoirement un rpm (aliené), ainsi qu'un paquet "source debian").

Voilà, pour moi, ça me semble ok, il me reste qques détails à faire (signature des paquets, description de multiples auteurs ...).

Mais j'aurai besoin de feedback, d'avis, sur la façon de consituer ce deb ... Si des spécialistes voulaient jeter un coup d'oeuil ...

J'ai vite fait une page à 2 sous ici :
http://manatlan.infogami.com/py2deb

et py2deb est livré en deb (fabriqué par lui même ;-)
http://manatlan.free.fr/setup/python-py2deb_0.3_all.deb
  • # setuptools ?

    Posté par  . Évalué à 2.

    Heu, vu ce que fait setuptools en standard, il ne doit pas manquer grand'chose pour lui faire créer des deb automatiquement (il y a déjà une commande bdist_rpm, mais pas bdist_deb).
    En cherchant un peu sur Google, j'ai trouvé ça : http://easy-deb.sourceforge.net/ et ça : http://stdeb.python-hosting.com/
    (je ne peux pas tester, je suis sous Mandriva :-))
    • [^] # Re: setuptools ?

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

      Parlons en ...

      Setuptools/distutils : c'est la méthode pythonesque de packager son programme. Depuis peu, il y a même les EGG (j'ai même fait un tuto là dessus). Et c'est, je pense, que c'est vers là qu'il faut aller !

      Mais je crois que la distribution de package python est en pleine mutation, car aux EGGs, se rajoute encore les 2 systèmes concurrents entre eux : pycentral et python-support (exclusivement debian, non ?)

      Malheureusement, c'est assez indigeste, et demande également beaucoup de temps (je trouve), et les tutos clairs ne sont pas légions. Pour ma part, pas plus tard qu'il y a une semaine, j'ai tenté de passer par setuptools pour générer un sdist (source distrib), ou un bdist_rpm (en vue de l'aliener en deb).
      J'ai bien passé 8h dessus, sans rien en sortir. Impossible de packager les "data_files" (installation de fichier data dans le FS, genre /usr/share/). ça n'a franchement pas l'air d'être possible, et on est apparemment obligé de passer par "package_data" (et donc de mettre les data dans la sous arbo de l'application).
      (pour comparer, avec le temsps de dev de py2deb : au bout de 2h j'avais des packages deb générés, avec des fichiers que je place où je veux)

      Je connaissais les 2 liens que tu donnes. easy-deb est certainement la meilleure solution (egg compliant), mais ce n'est plus maintenu, et c'est bien vieux (2005).
      L'autre, j'avais tenter stdeb, sans arriver non plus à mes fins, mais c'était avec la version 0.1 (j'ai vu que maintenant il y a de la 0.2 depuis 2007, faudra que je retente quand même)
      Il en existe d'autres, avec des front-end gui (ce que je comptais faire pour py2deb, mais j'ai pas l'impression que ça soit necessaire dans un premier temps)

      Bref, je ne desespere pas comprendre un jour les distutils, et un jour générer des deb via setup.py ... Mais en attendant, la méthode que je propose est bien plus rapide, plus simple, pour les gars qui n'ont pas le temps de plonger dans le packaging (et oui, on trouve de moins en moins de gars qui se propose de packager ton appli, du coup, le dev est obligé de le faire ;-)

      Bon, dans le monde ubu/debian, launchpad se propose de te packager tes applis en deb (multi architecture), tout en hostant un vrai repository deb. Il suffit juste de fournir un paquet source, et launchpad s'occupe du reste. (les fameux PPA de launchpad). Ce qui simplifie encore plus le problème de l'empaquetage (je n'ai pas encore essayer, mais c'est au programme)

      Maintenant, si qqu'un a un (ou des bons) tutos setuptools/distutils, je suis assez prenneur.
      • [^] # Re: setuptools ?

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

        autre chose importante ... que j'ai oublié

        Je crois qu'il est impossible de dire à setuptools, qu'on a besoin de programmes externes (non python) ... genre forcer l'installation "dpkg-dev" par exemple, quand ton prog a besoin de ces outils
      • [^] # Re: setuptools ?

        Posté par  . Évalué à 2.

        je crois que tu peux aussi rajouter scons, a priori numpy et scipy vont passer a terme pour remplacer setuptools.
        Sous python c'est un peu le merdier je dirais et je n'ai pas l'impression que les eeg regles beaucoup de choses en realite, enfin on verra. En attendant j'aimerai bien qu'un outil tel que py2exe ou py2app pour linux qui fonctionne...
        • [^] # Re: setuptools ?

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

          bah, py2deb permet facilement de déployer une appli python sur un poste debian ... au même titre que py2app pour mac, ou py2exe pour win ...

          Cependant, si tu cherches un bon freezer, qui fonctionne très bien sous linux (et win mac), il y a l'excellentissime pyinstaller
      • [^] # Re: setuptools ?

        Posté par  . Évalué à 2.

        Mais je crois que la distribution de package python est en pleine mutation, car aux EGGs, se rajoute encore les 2 systèmes concurrents entre eux : pycentral et python-support (exclusivement debian, non ?)

        Ce n'est pas vraiment "concurrent". Chaque distribution a ses outils dédiés pour gérer les packages. Si ta distrib fournit le paquet que tu veux, et que tu n'as pas besoin de la toute dernière version, alors il est recommandé d'utiliser le paquet fourni par la distrib.

        L'intérêt de setuptools c'est :
        1. de donner accès à des tas de paquets (bibliothèques, programmes) qui ne sont pas intégrés par ta distrib. Tu tapes "easy_install nom_du_paquet" et c'est fait.
        2. de te permettre d'installer facilement des versions "bleeding edge" voire des versions de développement si tu en as envie.

        C'est un peu comme recompiler un programme depuis ses sources (./configure etc.), sauf que setuptools facilite largement la tâche en l'automatisant, ainsi que la gestion des dépendances vis-à-vis d'autres paquets setuptools.

        Pour un développeur l'intérêt de setuptools est que c'est une méthode de déploiement qui marche sur toutes les plateformes, y compris sous Mac et Windows...
    • [^] # buildout

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

      Il existe aussi un bon moyen de distribuer du python, c'est de faire un buildout. J'ai traduit il y a peu un tutoriel sur le sujet :
      http://www.afpy.org/Members/ccomb/tutoriel-buildout
      (ou le même en statique http://ccomb.free.fr/buildout/tutorial.fr.html )
  • # dh_make ?

    Posté par  . Évalué à 1.

    J'avais plutot l'habitude de dh_make:
    http://www.debian-administration.org/articles/337

    Qu'est-ce que ça fait de plus ?
    • [^] # Re: dh_make ?

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

      Bah, ça evite surtout de devoir rentrer dans les arcanes de debian, de devoir comprendre toute la logique derrière la création de paquet, et l'edition de fichier debian/(rules|control...)
      Pour un dev python, par exemple, techniquement, il n'a plus besoin de se plonger dans ces problématiques, et devrait être en mesure de générer un deb correct, en python.
      Tout est masqué, il se retrouve, après la generation, avec son deb, comme si de rien n'était : il n'a plus qu'à le tester ...

      Disons que ça enlève une part importante de complexité. En partant du principe qu'un dev n'est pas obligé de savoir les mécanismes debian.
      • [^] # Re: dh_make ?

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

        dh_make dispose d'un mécanisme de template permettant plus ou moins de créer des répertoires debian plus proches de ton besoin.
        L'important est de savoir si le dit développeur compte distribuer ses paquets deb directement ou via Debian/Ubuntu. Il existe notamment des outils de tests, lintian et linda, qui permettent de valider en grande partie la qualité de ton paquet. Qu'il s'installe correctement chez toi n'est PAS un test valide.
  • # Une bonne doc en français

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

    pour faire des paquets propres, "à l'ancienne". La doc est issue de cours donné sur IRC (#ubuntu-fr-classroom) par des core-dev ubuntu

    http://doc.ubuntu-fr.org/projets/ecole/paquets

    \Ö<

    • [^] # Re: Une bonne doc en français

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

      oui, j'avais suivi même le premier cours en live ...
      mais comme dit, quand tu cherches juste à empaqueter les fichiers de ton programme python, afin de pouvoir le diffuser plus facilement. C'est trop complexe ...

      Je ne dis pas que c'est pas interessant, culturellement de connaitre les arcanes de debian. Mais souvent, toi, tu veux juste diffuser ton programme, et ne pas passer qques heures à faire ton paquet ...
      • [^] # Re: Une bonne doc en français

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

        Ce n'est pas non plus très compliqué. Si ça devient récurrent pour des modules Python, autant créer un patron qui permette de gagner du temps. Les développeurs Python ne sont pas obligés d'être les responsables des paquets de leurs propres modules au sein de Debian. En fait, un groupe de travail à l'image de celui pour Perl serait idéal.
  • # dh-make-python ?

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

    Tu pourrais sans doute t'inspirer de ce qui existe déjà pour les modules Perl ainsi que pour les modules PEAR et PECL pour PHP :
    - dh-make-perl[1] ;
    - dh-make-php.
    Tu pourrais ainsi créer dans la même idée un dh-make-python.

    [1]: http://www.debian-administration.org/articles/78
    • [^] # Re: dh-make-python ?

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

      comme dit, j'y connais vraiment pas grand chose dans tous ces outils debian ...
      mais c'est vrai qu'il devrait être possible de rapprocher les infos d'un distutils/setuptools avec ceux de py2deb, et peut être automatiser la generation d'un deb via le setup.py ...
      je regarderai de ce coté là ...
  • # Tutorial

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

    Vu le tutorial sur lequel tu sembles t'être basé, je trouve dommage que certains outils de debhleper soient toujours aussi méconnus et sous-utilisés.
    La commande dh_install rend de bien grands services et évite de se palucher les multiples commandes cp et mkdir : tu génères un fichier debian/install dans lequel tu consignes les fichiers à installer et leurs destinations respectives.
  • # hmhm

    Posté par  . Évalué à 1.

    Voici la manière dont je procède pour faire un paquet .deb:

    Soit un truc python à distribuer utilisant distutils.core.setup

    Créer un répertoire debian contenant changelog compat control control.in copyright rules.

    changelog s'édite avec dch

    compat contient 5

    control.in contient (à adapter...) :

    Source: sourcepackagename
    Section: comm
    Priority: extra
    Maintainer: maintainer <maintainer@kikoo.com>
    Uploaders: uploader1 <uploader1@kikoo.com>, uploader2 <uploader2@kikoo.com>
    Build-Depends: @cdbs@, python-support (>= 0.5.3)
    Standards-Version: 3.7.2.2

    Package: packagename
    Architecture: all
    Depends: python, python-mysqldb, python-sqlite
    Description: packagename is a cool package
    packagename is a cool package that rox
    .
    blablabla


    copyright contient la/les licences

    rules contient:

    #!/usr/bin/make -f
    # -*- makefile -*-

    DEB_PYTHON_SYSTEM=pysupport

    include /usr/share/cdbs/1/rules/debhelper.mk
    include /usr/share/cdbs/1/class/python-distutils.mk
    include /usr/share/cdbs/1/rules/simple-patchsys.mk


    control est généré à partir de control.in avec un commande de ouf que j'ai oublié (mais qui est facilement retrouvable :)

    C'est très facile d'intégrer ça à n'importe quel build sys, qu'il soit en bash, Makefile, scons.

    C'est aussi très facile à créer, il suffit d'avoir un template dans un coin et on peut éventuellement faire un petit script pour remplir 99% du template.
    • [^] # Re: hmhm

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

      c'est interessant ... si tu as des pointeurs sur un tuto ... suis prenneur aussi
      • [^] # Re: hmhm

        Posté par  . Évalué à 1.

        hm j'ai un Debian Developer à 3m de moi au bureau, ça aide :)
        Si j'arrive à le cloner je t'en enverrais une copie ;)
        • [^] # Re: hmhm

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

          cependant t'avouera que c'est plus simple de faire ça directement en python, quand on est un dev python ...

          le cas le plus simple, en 4 lignes de code :

          from py2deb import Py2deb
          p=Py2deb("myprogram")
          p["/usr/bin"] = ["myprogram",]
          p.generate("0.2")

          sans se prendre le choux avec tous les fichiers debian ....
          • [^] # Re: hmhm

            Posté par  . Évalué à 1.

            Ouai c'est sympa (de toute manière dès que je vois du Python je trouve ça sympa :)

            Bien sûr tout dépend du contexte.

            Pour info la méthode décrite plus haut se place dans le contexte suivant (mais elle peut probablement être pratique dans d'autres) :

            on a un assez gros build sys chargé de construire pleins de composant écrit en pleins de langages différents, constituant des logiciels dont nous ne sommes pas forcement l'upstream mais parfois si, avec des dépendances dans tous les sens et une pincées de flavours à gérer, sans compter qu'au final on upload dans de multiple repository (par version, ce qui est plus pratique que de postixer le numéro de version dans le nom dans notre cas et étant donné nos process de devel). Du fait de tout ce qui précède il y a plusieurs répertoires Debian possibles par composant. Enfin les paquets destinés à de la prod. (et dans une certaine mesure des paquets de dev. le sont aussi) sont buildés sur des machines dédiés dont l'environnement est contrôlé, car sur certains composants tiers essentiels on a un risque de changement du résultat du build en fonction des paquets installés sur l'hôte, donc pour obtenir un build reproductible une machine dédiée à cette tache est bienvenue.

            Du coup le build et le packaging se font en multiples étapes (toutes automatisées) et ces aspects sont principalement gérés par le Debian Developer, et grâce à setuptools je ne me préoccupe généralement que d'un setup.py quand je fait un peu de Python :

            from distutils.core import setup

            setup(name='bla',
            version='1.0',
            description='Useful python libraries',
            author='somebody',
            author_email='tech@kikoo.tld',
            url='http://kikoo.tld/',
            packages=['kikoo', 'kikoo.Lol'],
            )

            D'ailleurs je ne sais pas très bien ce que python-distutils.mk fait des infos que je donne la dedans d'ailleurs. Il faudra que j'enquête un jour sur la question :p (à mon avis seul packages et ptet name sont utiles dans ce contexte)

Suivre le flux des commentaires

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