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 :
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)
[^] # Re: hmhm
Posté par Guillaume Knispel . En réponse au journal py2deb : fabriquer des debs facilement .... É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)