[Python & .DEB] Créer un paquet DEB d'un programme en Python

medim · Le 12/08/2007, à 13:55

Peut-être que python n'en a pas besoin, mais ce n'est peut-être pas le cas des utilisateurs

Leonux · Le 12/08/2007, à 17:27

Et pourtant... Python est transcendant des systèmes d'exploitation. Voir Python au travers d'une lunette Linux/Ubuntu est une erreur.

Ben oui, mais ici, on est dans un forum GNU Linux basé sur des paquets .deb ...

aleph · Le 12/08/2007, à 21:14

Oh, je n'insiste pas. C'est juste pour signaler, si je peux me permettre, quelques petites applications Python. Elles font le bonheur des amateurs de Python sous Windows, Linux (toutes distributions confondues) ou OS X (en autres). Ici : http://spinecho.ze.cx/

----

"L'Homme le plus libre est celui qui a le plus de relations avec ses semblables.."

Comme cela s'applique à merveille dans le monde Python !

ekingr · Le 15/12/2007, à 19:50

Salut à tous (bien que ce post date un peu ...)
J'ai lu avec intérêt le cours de votre "petite histoire" et je voudrais savoir si l'un de vous à finalement rédigé une procédure concrète qui permettrai à un débutant sous Ubuntu (mais pas avec Python) tel que moi de savoir comment créer un paquet pour une application Python.
Si non, pourriez-vous le faire, même si c'est de manière rapide.
Merci d'avance.

manatlan · Le 04/01/2008, à 00:07

Moi aussi, j'ai été confronté à tous ces problèmes. Et je n'arrive décidément pas à me mettre à distutils/egg ... Recemment j'ai du passé une journée à tenter de faire ça dans les règles de l'art, tenter de builder un rpm via les setuptools, en vue de l'aliener en deb ... Mais impossible à faire ...

J'ai fini par me lancer dans la création d'un module python 'py2deb' permettant de fabriquer simplement (vraiment simplement) un package deb (avec en sus : un packager rpm et sources) ...

http://manatlan.infogami.com/py2deb

Evidemment, ça ne doit pas couvrir 100% des possibilités offertes par debian, mais je pense que ça devrait ravir pas mal de monde, et permettre de diffuser simplement ses créations ... De plus ce n'est pas fait exclusivement pour livrer ses fichiers py, techniquement ça devrait marcher pour tout ce qui est distribution de fichiers ....

j'ai besoin de feedback ...

aleph · Le 04/01/2008, à 13:34

> manatlan

> j'ai besoin de feedback ...

> ...Et je n'arrive décidément pas à me mettre à distutils/egg ...

distutils ou Python egg ne sont pas faits pour distribuer des applications pour les utilisateurs, mais pour distribuer des modules/bibliothèques, parfois des applications tests liées aux libs précédentes qui étendent la structure de Python.

> ...un package deb...

Tu peux très bien créer un paquet deb, rpm ou .... Dans ce cas, tu ne fais qu'ajouter des contraintes à l'utilisateur de tes scripts Python, contraintes qu'il n'aurait pas si tu distribuais directement tes scipts Python.

Distribuer des scripts Python sous forme de paquets n'a pas grand sens. Ce serait similaire à vouloir distribuer un fichier html ou od* dans un paquet deb ou rpm !

(Un peu surprenant pour quelqu'un qui maà®trise aussi bien Python.)

ekingr · Le 04/01/2008, à 15:18

Cool
J'ai créé un paquet pour un petit démineur que j'avais (même pas fini de) codé (mais il est quand même fonctionnel).
Essaie-le chez toi; et si ça marche, ton module aura passé le baptême du feu !
Manque plus qu'une doc un peu plus explicite
@+

ekingr · Le 04/01/2008, à 15:29

aleph a écrit :

Tu peux très bien créer un paquet deb, rpm ou .... Dans ce cas, tu ne fais qu'ajouter des contraintes à l'utilisateur de tes scripts Python, contraintes qu'il n'aurait pas si tu distribuais directement tes scipts Python.
Distribuer des scripts Python sous forme de paquets n'a pas grand sens. Ce serait similaire à vouloir distribuer un fichier html ou od* dans un paquet deb ou rpm !
(Un peu surprenant pour quelqu'un qui maà®trise aussi bien Python.)

L'avantage des paquets c'est qu'ils gèrent les dépendances, ce qui est très intéressant pour les scripts Python qui utilisent souvent de nombreux modules pas intégrés dans la version standard.
De plus, si le soft. Python utilise des images, des fichiers de configurations ou des modules perso et que tu veux qu'il puisse être accessible à partir du menu Applications tout en mettant à disposition de tes utilisateurs un moyen d'installation simple, les paquets on la meilleure solution. Quoi de plus déroutant pour un ubuntero débutant que de devoir manier les /usr /bin, /urs/lib ... ? (je peux l'attester personnellement)
Enfin, c'est le meilleur moyen pour gérer aisément les nouvelles versions et assurer une installation stable (du moins plus que celle faite "à la main" par un novice)

___________
PS: Désolé pour le double post

bipede · Le 04/01/2008, à 17:34

aleph a écrit :

Tu peux très bien créer un paquet deb, rpm ou .... Dans ce cas, tu ne fais qu'ajouter des contraintes à l'utilisateur de tes scripts Python, contraintes qu'il n'aurait pas si tu distribuais directement tes scipts Python.
Distribuer des scripts Python sous forme de paquets n'a pas grand sens. Ce serait similaire à vouloir distribuer un fichier html ou od* dans un paquet deb ou rpm !
(Un peu surprenant pour quelqu'un qui maà®trise aussi bien Python.)

Dans l'absolu, tu as raison...
Mais pour l'utilisateur lambda, la distribution sous forme de .deb ou .rpm n'est pas une contrainte, bien au contraire... Un deb bien réalisé contrà´le les dépendances et les installe automatiquement.
Bien des utilisateurs sont contrariés de devoir installer manuellement plusieurs paquets avant de pouvoir utiliser un soft en python (beaucoup sont même surpris qu'un .py puisse être exécutable).
C'est la même chose sous win, oà¹ de nombreux utilisateurs préfèrent un exe fabriqué avec py2exe, car il ne comprennent pas bien les principes des langages de script.

@ manatlan

Ton soft me semble particulièrement pratique...
Je m'en vais étudier ça de près...

manatlan · Le 04/01/2008, à 17:58

aleph a écrit :

Distribuer des scripts Python sous forme de paquets n'a pas grand sens. Ce serait similaire à vouloir distribuer un fichier html ou od* dans un paquet deb ou rpm !
(Un peu surprenant pour quelqu'un qui maîtrise aussi bien Python.)

Les autres ont déjà répondu ...
Là il n'est pas question de distribuer des scripts ou des modules python. Mais bel et bien des applis python (avec dans data dans /usr/share, des doc dans /usr/share/doc, un .desktop, des fichiers de config ...). Distutils/setuptool/egg sont incapables de faire installer une dépendances non python.
exemple simple ... bien py2deb soit un module python ... Je voulais le releaser en EGG, mais impossible de lui mettre les dépendances sur dpkg-dev, fakeroot, alien, ... Alors que sans ces derniers ce module n'a pas de sens ....

ekingr a écrit :

J'ai créé un paquet pour un petit démineur que j'avais (même pas fini de) codé (mais il est quand même fonctionnel).
Essaie-le chez toi; et si ça marche, ton module aura passé le baptême du feu ! big_smile
Manque plus qu'une doc un peu plus explicite roll

Nickel ... tu as l'air d'avoir bien compris le peu de doc explicite ;-)
installé avec gdebi, par un 2clic ... et icone et tuti canti sont là ...

aleph · Le 04/01/2008, à 19:54

> bipede

Je n'ai pas raison parce que je suis convaincu de ce que j'ai écrit. J'ai raison parce ce que c'est le principe de fonctionnement de Python qui l'exige, quelle que soit la plateforme (un linux, un Windows, un OS X ou Solaris). Les sytèmes d'installation de paquets sous Linux, setup/install sous Windows ou ports sous BSD ne dérogent pas et *ne peuvent pas* déroger à cet état de fait.

Il est obligatoire d'écrire son application Python en fonction de ce que le "site-packages" contient et d'informer l'utilisateur des bibliothèques que le/les scripts utilise/utilisent.

> Un deb bien réalisé contrà´le les dépendances et les installe automatiquement.

Il est illusoire de croire que l'on pourra résoudre le problème des dépendances d'une application Python en faisant installer les bibliothèques manquantes de site-package. Cela ne fonctionne pas, ne fonctionnera pas et ne fonctionnera jamais comme ceci, même avec Python 3. Ceci quelle que soit la plateforme sur laquelle Python est installé.
Cela ne devrait pourtant pas très sourcier à comprendre pour un développeur Python.

> ... contraintes...
Je laisse tomber, cela ne concerne pas les modules mais les droits d'installation (entre autre).

------

> manatlan
> Là il n'est pas question de distribuer des scripts ou des modules python. Mais bel et bien des applis python (avec dans data dans /usr/share, des doc dans /usr/share/doc, un .desktop, des fichiers de config ...). Distutils/setuptool/egg sont incapables de faire installer une dépendances non python.

Ah, tu me rassures. Effectivement, si tu veux distribuer, installer des outils autres tels que de la doc répartis dans divers répertoires, un paquet deb ou rpm fera très bien l'affaire. Il est à noter que si les Python eggs ne conviennent pas très bien, c'est justement parce qu'ils sont conçus pour distribuer des extensions de Python et non ce genre de chose.

Toutefois, il est aussi possible de moduler son application de façon un peu plus "moderne". La démo de wxPython est un très bel exemple. http://www.wxpython.org/download.php

La démo de Python, c'est
- 410 modules Python
- plus de 200 png, bmp, ....
- 9 fichiers html
- une aide en chm pour Windows de plus de 3 Mb (aussi disponible en html)
- quelques fichiers texte
- quelques utilitaires
- ...

et tout cela fonctionne sur une simple clé usb, ... sans aucune installation et sous toutes les platformes !

La démo de pyQt, que je connais moins, est de la même veine.

manatlan · Le 05/01/2008, à 13:22

aleph a écrit :

Ah, tu me rassures ...

ah bah, je suis rassuré que je te rassure ...

sinon la demo de wxpython (sous nux), c'est un gros tar.gz, avec tout dedans, et plein des chemins relatifs ...(sous win, c un exe, certainement builder avec les setuptools)
(avant c'était en deb/rpm, mais comme dit sur le site, ça installait les fichiers avec les droits root, et du coup, ça ne permettait pas de hacker facilement le code, du coup : ils ont abandonné)

sinon j'ai aussi posté sur dlfp l'annonce de py2deb ... et qques spécialistes indiquent d'autres méthodes interessantes : http://linuxfr.org/~manatlan/25930.html
cependant, py2deb reste eminament plus simple ...pour un pythonistas qui ne veut pas se plonger dans les arcanes des packages debian ... tout en restant, plus simple, que setuptools/distutils, qui ne fait toujours pas les deb (sans stdeb et autres).

Dernière modification par manatlan (Le 05/01/2008, à 13:27)

Bismut · Le 05/01/2008, à 13:35

manatlan > Je n'ai pas testé ton code, mais je développe en XUL et déploie mon application avec XULRunner.
Ca doit reprendre un peu le même principe qu'avec Python puisque c'est un langage non compilé, c'est même plus simple car je n'ai aucune dépendance, mon soft marche à partir de son dossier.

Serait-il envisageable de faire marcher ton "packager de .deb pour Python" pour un autre langage interpreté comme XUL ?

Ce serait génial, ça apporterait :
- Icone et ajout au menu automatique
- Facilité d'installation et de MAJ

Merci d'avance si jamais c'est réalisable.

manatlan · Le 05/01/2008, à 14:27

@bismut

py2deb n'est pas limité à empaqueter du python dans du deb (ça a juste besoin de python pour generer le deb). Tu devrai pouvoir sans problème, empaqueter n'importe quoi d'autres (pour peu que ça reste de la simple copie de fichiers à des endroits bien précis : no prob)

Bismut · Le 05/01/2008, à 14:52

Génial, je teste ça dès que possible !

ekingr · Le 05/01/2008, à 16:05

Oui, c'est sûr ...
Maintenant, il serai presque possible de créer un utilitaire graphique permettant d'empaqueter n'importe quelle application.

Bismut · Le 05/01/2008, à 17:02

Je ne suis pas certain de bien comprendre comment adapter, enfin faire marcher py2deb pour créer un .deb de mon logiciel en XUL et non en Pyhton.

Voilà ce que j'ai :

- Un répertoire contenant mon logiciel qui démarre en double-cliquant sur mon exéctubale : yLife (mon logiciel contient quelques centaines de fichier)

- J'ai installé py2deb qui a installé fakeroot en dépendance.

Je fais quoi ? Des commandes en terminal ? Je créé un fichier de config ? Je comprends pas très bien les exemples de la doc.

Merci

Dernière modification par Bismut (Le 05/01/2008, à 17:04)

aleph · Le 05/01/2008, à 17:34

> manatlan

Quelques commentaires sur la démo de wxPython et plus générallement sur la façon
de travailler pour qu'un script Python puisse importer des modules et autres
fichiers tiers (fichier d'aide, de configuration ou d'images, par ex).

> sinon la demo de wxpython (sous nux), c'est un gros tar.gz, [...]
> (sous win, c un exe, certainement builder avec les setuptools)

Attention à ne pas tout mélanger. La démo de wxPython est une application
"standalone" qui fonctionne sur toutes les platformes pour autant que
la bibliothèque wxPython et Python soient installés (évidemment). Certains
modules (rares) nécessitent numpy. Pour les platefomes *ix ou *ux la démo
est empaquetée dans un tar. De cette façon, elle est diponible pour toutes
les versions de *ix ou *ux, sans qu'il ne soit nécessaire de créer un paquet
pour chaque distribution (C'est le thème de ce fil de discussion).
La version exe pour Windows, n'est rien d'autre que le fichier tar, plus
quelques "goodies" comme la création de menus sur la platforme hà´te. Il est
tout à fait possible pour un utilisateur de Windows de se contenter de
dépaqueter le tar.gz et d'éxécuter la démo. Comme le serait n'importe quel
autre application Python. Cette façon de faire est probablement la meilleure
face à la diversité des distributions Linux.

L'exe pour Windows est construit avec InnoSetup.

> [...] plein des chemins relatifs [...]

Parce que c'est la façon de faire et de travailler proprement avec Python.
Toutes les bonnes applications, même les plus compliquées (centaines de modules
et autres fichiers divers) sont développées selon ce mécanisme, décrit
brièvement ci-dessous.

1) Une application Python (générallement le script main) récupère son propre
chemin.

2) Le développeur d'une application conaissant la structure de son application
(sous-répertoires, ...) va créer les chemins d'accès nécessaires à son
application.

3) Pour l'importation et la recherche des modules nécessaires à l'application,
le développeur va adapter le sys.path en conséquence. Ceci est un point très
important, dans une application et lors de son exécution, le sys.path
"temporaire" ne "vivra" que pendant l'exécution de celle-ci. Quand l'application,
rend la main au système, le sys.path est dans le même état que lors du lancement
de l'application.

Ce méchanisme à comme avantage de rendre l'application indépendante du système,
c'est à dire du sys.path par défaut du système. L'application peut être exécutée
à partir de n'importe quel répertoire, même une clé usb. Il permet aussi
d'utiliser et d'avoir accès à des modules tiers (d'autres développeurs, par ex)
sans que ceux-ci soient installés dans la structure Python du système.
Accessoiremnt, il n'est pas nécéssaire que ces modules tiers soient disponibles
via un quelconque système de déploiement (exe, rpm ,deb, dmg).

Une myriade de modules Python sont ainsi dispobibles à tout utilisateur, sans
aucun mécanisme d'installation et qui plus est, jamais ces modules ne seront
mis à disposition d'un utilisateur potentiel par une installation ou ne se
trouveront dans un dépà´t, car cela n'est pas nécessaire.

La démo de wxPython, comme bien d'autres applications, fonctionne de cette
manière en jouant avec les sys.path et os.path.

L'application pypar2, proposée en début de ce fil de discussion, est à mes yeux
une application qui souffre d'un manque de compréhension de ce mécanisme.
En examinant le code source, terme un peu éxagéré quand on parle de scripts
Python, on ne voit nul part mention d'une adaptation du sys.path. pypar2 doit,
par conséquent, reléguer à des systèmes d'installation les chemins des recherches
du modules avec pour corollaire un système de distribution différent pour chaque
version (ubuntu, debian, fedora) alors qu'un script bien conçu se suffirait à
lui même. Accessoirement, cela permettrait à chaque utilisateur d'installer le
script oà¹ il le désire et surtout, point non ngligeable, ne requière aucun droit
d'administrateur.

Un petit mot sur les eggs et sys.path. Les eggs sont conçus pour étendre
la stucture de Python et non conçus pour le déploiement d'application.
La particularié des eggs est qu'ils - parfois - étendent le sys.path du système.
Si un million d'utilisateurs distribuait ses applications de cette manière,
le nombre d'items du sys.path atteindrait inutilement ce million et rendrait
la structure de Python quasiment inutilisable, car trop "polluée" de chemins de
recherche inutiles.

Dans ce mechanisme de recherche de modules, d'autre voies sont utilisables.
Dans bon nombre de mes applications, les bibliothèques partagées se trouvent
dans un répertoire dédié, complètement indépendant de la stucture de Python.
Ces modules sont accessible via un fichier .pth.

A mes yeux le déploiement d'applications Python via la distribution de scripts
reste le méthode qui, si elle n'est pas parfaite, reste la plus souple qui soit.
Python par lui-même permet de faire face à n'importe quelle situation.

La modularité de Python permet l'utilisation de n'imorte quel module (à moins
que ceux-ci ne soient spécifiques à une platforme). Un point important à ne
pas négliger est la foison de modules diponibles qui de toute façon ne seront
jamais mis à disposition via un système de dépà´ts, de ports ou de setup, car
c'est heureusemnt inutile.

Une source de modules Python pur sucre assez intéressante: on y trouce de tout
du bon et du moins bon, la particularité de ce site réside dans le fait
que quelques modules sortent du lot, à tel point qu'ils seront intégrés
dans la prochaine mouture de Python.
http://aspn.activestate.com/ASPN/Cookbook/Python/

PS Je connais assez bien la démo de wxPython parce que teste chaque nouvelle
version et ai accesoirement écrit un modeste petit bout comme bien d'autres
utilisateur / contributeurs au projet wxPython.

PS2 La prochaine version de wxPython devrait voir le jour d'ici la fin du mois
de janvier.

En espérant ne pas avoir été trop long.

manatlan · Le 05/01/2008, à 18:23

@bismut ..

bah tu créé un fichier python (genre à la racine de ton appli): genre build.py
et tu lui colles ça :

from py2deb import Py2deb

p=Py2deb("aeff")
p["/usr/share/ton_appli/"] = ["fichier1","fichier2",]
p.generate("0.1")

et tu complètes ...
mais c sure, il faut un peu s'y connaitre en python, pour être efficient
faut aussi un peu connaitre comment et oà¹ on doit stocker les fichiers, ainsi que comment son appli marche, et comment adapter les path, si on met des fichiers un peu partout dans le file system

ekingr a écrit :

Oui, c'est sûr ...
Maintenant, il serai presque possible de créer un utilitaire graphique permettant d'empaqueter n'importe quelle application.

C'était le but à la base ... rajouter un frontend gtk pour simplifier la saisie ...
mais ce serait assez complexe pour couvrir toutes les façons d'associer des fichiers ... donc pour l'instant, en code python, c plus simple

@aleph
long, mais interessant ... et je suis d'accord ...
(cependant suis vraiment pas un fan de wx (par experience), j'avais une appli dev sous wx, sous windows, et elle ne marchait vraiment pas sous nux out of the box ... et j'ai du adapter pas mal de code pour qu'elle puisse marcher sur les 2 os (cas frequent quand on utilise les widgets dans leurs retranchements : ils ne fonctionnent pas tous pareil sous win et sous nux) (bon c'était en wx 2.4 jadis)... alors qu'avec gtk : il n'y a rien à faire du tout, c'est identik (mais moins beau sous win) ... mais là on sort du sujet grave)

Bismut · Le 05/01/2008, à 19:18

Ok, je comprends comment ça marche
Mais dans le détail, je n'ai pas un grande connaissance du formalisme sous Linux et Gnome en particulier.

- Dois-je copier mon logiciel dans usr/lib ? Je n'ai pas encore de Doc.

- Comment faire pour ajouter une entrée au Menu de Gnome ? Avec une icà´ne si possible

- Comment copier tous les fichiers de mon logiciel ? J'en ai quelques centaines, je me vois mal les ajouter un par un... Peut-on mettre des Dossiers dans ta syntaxe ?
Ou faut-il créer un semblant de fonction récursive qui entre dans chaque dossier ? Car je ne connais pas du tout le python, même si d'un point de vue algorithmique ça ne doit pas être trop compliqué.

manatlan · Le 05/01/2008, à 19:46

oui, py2deb facilite la création de deb, mais encore faut il savoir comment est architecturé l'arborescence d'un file system linux ... ça py2deb ne peux pas te l'expliquer ...
Il y a des doc là dessus plein le web

> Dois-je copier mon logiciel dans usr/lib ? Je n'ai pas encore de Doc.
matte oà¹ sont stockés les applis similaires ... tente de faire un peu pareil
(dans synaptic, choisi un prog installé, choisi ses "proprietes", et matte l'onglet "fichiers installés")

cependant, il faut aussi que l'appli, une fois installé sache oà¹ chercher ses billes ... ça dépends aussi beaucoup de comment l'appli est codé

genre le fichier executable devrait plutot etre dans /usr/bin ...
les libs (et plugins) dans /usr/lib/<ton_appli>
les data dans /usr/share/<ton_appli>
l'entree menu (.desktop) dans /usr/share/applications
après, ça dépends aussi beaucoup, de comment l'appli est architecturée, et comment elle veut partager des choses avec les autres ... (ex: pidgin, met ses images dans /usr/share/pixmaps, pour les partager, et possède même un deb dedié à ça, ça lui donne une certaine modularité ... d'autres mettent leurs images dans /usr/share/<ton_appli>)

> Comment faire pour ajouter une entrée au Menu de Gnome ? Avec une icà´ne si possible
là , il faut créer un fichier .desktop (cf norme freedesktop)
les .Desktop, ça va, generallement, dans /usr/share/applications

> Comment copier tous les fichiers de mon logiciel ?
utilise glob (cf doc python sur glob) et concatene les list, ou autres (genre path.walk et cie)

> Peut-on mettre des Dossiers dans ta syntaxe ?
non, c fait expres ... (plutot explicite qu'implicite, "axiome pythonesque")

avant de te plonger dans py2deb, et la creation d'un "deb à tous prix", je te conseille quand même de lire un peu de doc sur comment organiser ton appli dans le FS (file system), et eventuellement adapter ton appli suivant comment tu as décidé de stocker tes fichiers ....

Dernière modification par manatlan (Le 05/01/2008, à 19:58)

Bismut · Le 05/01/2008, à 20:14

Ok, merci beaucoup tu as déjà répondu à beaucoup de mes interrogations.
Je sais maintenant à quoi sont "a priori" destinés ces dossiers clés (lib, share,...)

Le fait que l'intérêt de XUL (comme Firefox) est qu'avec le même code, mon appli. marche sur Windows, Linux et Mac et c'est vrai que de par son architecture même, il n'est pas aisé de respecter toutes les normes de Freedesktop/Gnome, sinon on perd l'avantage du multi-plateforme simple si on commence à spécialiser pour chaque plate-forme.
Je pense que je vais me limiter usr/lib/ dans un premier temps ça devrait faire l'affaire.

Pour le .desktop, m'en vais de ce pas explorer ça sur freedesktop.

Et pour le gros du travail, à savoir l'ajout de tous mes fichiers via glob, je vais également faire des recherches de ce cà´té.

Merci beaucoup pour ton aide, j'espère bientà´t pouvoir présenter mon petit .deb

manatlan · Le 05/01/2008, à 20:24

sinon, je crois que je vais me lancer dans un frontend gtk .... g une idée pas mal

ekingr · Le 06/01/2008, à 00:36

Si tu veux, je peux te filer un coup de main, j'ai aussi une plutà´t bonne vision de ce à quoi ça devrai ressembler ...

Bismut · Le 08/01/2008, à 17:50

Bon, j'ai un souci tout bête, j'arrive pas à lancer mon build XD, soyez indulgents je ne connais absolument pas le Python. ^^"

- J'ai mon logiciel dans /yLife et mes icones et .dekstop dans /yLife_Linux

- J'ai mon build_yLife.py à la racine de ça :

from py2deb import Py2deb
from glob import glob

version="0.5.6"
changelog=open("yLife/Changelog.txt","r").read()

p=Py2deb("yLife")
p.author="Raphael Rigaud"
p.mail="raph.rigaud@gmail.com"
p.description="""Un logiciel complet pour Yu-Gi-Oh! TCG."""
p.url = "http://ylife.sourceforge.net"
p.license="gpl"
p.section="games"
p.arch="all"

p["/usr/lib"] = glob("yLife/*")
p["/usr/share/app-install/icons"] = ["yLife_Linux/yLife.png",]
p["/usr/share/app-install/desktop"] = ["yLife_Linux/yLife.desktop",]

print p

- J'ai mis les droits en 777 et l'exécution à mon fichier .py

- J'ai ouvert un Terminal grà¢ce à un Nautilus-script pour me placer à la racine de mon build_yLife.py et je tape : build_yLife. Rien ne se passe. J'ai tenté : build_yLife.py mais rien non plus.

Ca doit être tout bête mais bon...

Merci d'avance pour votre aide

PS : J'ai un doute sur glob : Est-ce qu'il ne prend qu'un niveau de répertoires ou bien c'est récursif et ça prend tous les sous-répertoires ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 12/08/2007, à 13:55

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#27 Le 12/08/2007, à 17:27

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#28 Le 12/08/2007, à 21:14

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#29 Le 15/12/2007, à 19:50

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#30 Le 04/01/2008, à 00:07

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#31 Le 04/01/2008, à 13:34

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#32 Le 04/01/2008, à 15:18

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#33 Le 04/01/2008, à 15:29

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#34 Le 04/01/2008, à 17:34

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#35 Le 04/01/2008, à 17:58

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#36 Le 04/01/2008, à 19:54

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#37 Le 05/01/2008, à 13:22

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#38 Le 05/01/2008, à 13:35

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#39 Le 05/01/2008, à 14:27

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#40 Le 05/01/2008, à 14:52

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#41 Le 05/01/2008, à 16:05

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#42 Le 05/01/2008, à 17:02

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#43 Le 05/01/2008, à 17:34

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#44 Le 05/01/2008, à 18:23

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#45 Le 05/01/2008, à 19:18

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#46 Le 05/01/2008, à 19:46

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#47 Le 05/01/2008, à 20:14

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#48 Le 05/01/2008, à 20:24

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#49 Le 06/01/2008, à 00:36

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

#50 Le 08/01/2008, à 17:50

Re : [Python & .DEB] Créer un paquet DEB d'un programme en Python

Pied de page des forums