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
Journal py2deb : fabriquer des debs facilement ...
4
jan.
2008
# setuptools ?
Posté par Antoine . Évalué à 2.
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 manatlan (site web personnel) . Évalué à 1.
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 manatlan (site web personnel) . Évalué à 1.
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 abramov_MS . Évalué à 2.
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 manatlan (site web personnel) . Évalué à 1.
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 Antoine . Évalué à 2.
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 ccomb (site web personnel) . Évalué à 1.
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 fleny68 . Évalué à 1.
http://www.debian-administration.org/articles/337
Qu'est-ce que ça fait de plus ?
[^] # Re: dh_make ?
Posté par manatlan (site web personnel) . Évalué à 1.
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 Raphaël SurcouF (site web personnel) . Évalué à 2.
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 Effraie (site web personnel) . Évalué à 1.
http://doc.ubuntu-fr.org/projets/ecole/paquets
\Ö<
[^] # Re: Une bonne doc en français
Posté par manatlan (site web personnel) . Évalué à 1.
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 Raphaël SurcouF (site web personnel) . Évalué à 2.
# dh-make-python ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
- 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 manatlan (site web personnel) . Évalué à 1.
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 Raphaël SurcouF (site web personnel) . Évalué à 2.
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 Guillaume Knispel . Évalué à 1.
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 manatlan (site web personnel) . Évalué à 1.
[^] # Re: hmhm
Posté par Guillaume Knispel . Évalué à 1.
Si j'arrive à le cloner je t'en enverrais une copie ;)
[^] # Re: hmhm
Posté par manatlan (site web personnel) . Évalué à 1.
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 Guillaume Knispel . Évalué à 1.
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.