Archive:Fr FR/Empaqueter/Python


 * Version: 0.4
 * Dernière révision: 16 Décembre, 2007

= Astuces sur la manière de créer des packages pour les modules Python =

Version de Python
Dans le passé (FC3 et antérieur) il était obligatoire d'ajouter la ligne Requires:      python-abi = %(%{__python} -c "import sys ; print sys.version3 ")

au fichier spec pour demander un version spécifique de python-abi. Ce n'est plus nécessaire dans FC4 et postérieur car rpm ajoute maintenant de lui même une dépendance automatique sur python(abi).

Architecture Système
Si vous souhaitez tout installer dans le répertoire global du site, utiliser ce truc: définissez python_sitelib en haut de votre specfile:

%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib")}

Sur un système i386 avec python-2.4, par exemple, %{python_sitelib} devient. Durant %install ou lorsque vous listez %files, vous pouvez utiliser le macro %{python_sitelib} pour spécifier la location (path). Par exemple:

%files %defattr(-,root,root,-) %dir %{python_sitelib}/modulename %{python_sitelib}/modulename/*.py %{python_sitelib}/modulename/*.pyc

Pour les modules Python inclus dans les librairies spécifiques à l'architecture système (comme quelque chose écrit en C), vous pouvez utilisez en plus:

%{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")}

Cela garantira que ce package sera installé correctement pour les libraires multi-architectures. En utilisant ces macros au lieu de modifier directement le specfile, vos réglages restent compatibles avec la version installé de Python même quand le répertoire racine change radicalement (par exemple, si python_sitelib) change en %{_datadir})

Vous ne devez pas compter sur INSTALLED_FILES, car il ne peut lister les répertoires, qui ont besoin d'être spécifié dans la section %files si besoin. Utiliser les globales dans la section %files est plus sécurisant.

setuptools/eggs
Dans le passé, Fedora a fait le minmum pour assurer le support d'eggs dans ses distributions. La  documentation complète (en anglais) inclus des exemples pour savoir quoi faire. Comme eggs est utilisé assez fréquemment, nous devons avoir une documentation plus compréhensible pour savoir comment l'utiliser. Voici un comparatif avantages/critiques pour en savoir plus :
 * Doit être fait: Python eggs doit être construit depuis les source. Il n'est pas possible de le glisser directement dans un répertoire.
 * Doit être fait: Python eggs ne peut pas télécharger de dépendances durant la compilation.
 * Doit être fait: Si les fichiers egg-info sont généré par des module de scripts, ils doivent être inclus dans le package.
 * Doit être fait: Quand un package compact est créer, il doit être installer en utilisant easy_install - pour éviter tout conflit avec le package principal.
 * Doit être fait: Quand sont créer plusieurs versions (pour un package compacte), un de ces packages doit contenir une version par défaut qui est utilisé par "import MODULE" sans aucune procédure d'installation.
 * Non obligatoire: Un package qui doit être utilisé par une autre interface via une interface egg peut contenir des infos pour egg.

Compilation des fichier binaires
Python va essayer automatiquement de compiler les fichiers binaires lorsqu'il les exécute afin d'accélérer les prochains lancements. Ces fichier sont enregistrés dans des fichiers avec l'extension .pyc (compiled python) ou .pyo (optimized compiled python). Ces fichiers sont du code binaire portable grâce à OSes. Si vous ne les incluez pas dans vos packages, python va essayer de les créer lorsque l'utilisateur lancera le programme. Si l'administrateur système les utilise, les fichiers seront également écrit. Plus tard, lorsque le package sera supprimé/retiré, les fichiers .pyc et .pyo devront être enlever manuellement du système de fichier. Cela afin de vous permettre de gagner du temps si vous avez besoin de compiler les fichiers pourcréez votre package et inclure les fichiers indiqués dans la section %files.

Si vous devez uniquement compiler pour FC>=4 et RHEL>= 5, rpm dispose d'un script vous permettant de créer le fichier pour vous. Toutes les modifications effectués seront enregistré dans votre fichier spec. Voici la procédure:

%install install -d %{python_sitelib}/foo install -pm 0644 foo.py %{python_sitelib}/foo/

Sinon:

%files %dir %{python_sitelib}/foo %{python_sitelib}/foo/foo.py %{python_sitelib}/foo/foo.pyc %{python_sitelib}/foo/foo.pyo

ou:

%files %dir %{python_sitelib}/foo %{python_sitelib}/foo/foo.py*

ou encore:

%files %{python_sitelib}/foo/

Avec les version de Fedora inférieures à 4 et de RHEL inférieur à 5, vous devez générer les fichiers .pyc et .pyo vous-même :

%{__python} setup.py install --skip-build --root $RPM_BUILD_ROOT %{__python} setup.py install -O1 --skip-build --root $RPM_BUILD_ROOT

Et rappelez vous d'ajouter les fichiers .pyc et .pyo dans votre section %files.

Inclure pyos
Dans le passé, il était coutume de %ghost vos fichiers .pyo pour gagner un peu d'espace disque. Désormais, vous avez deux possibilités:
 * 1. Avec SELinux, si un utilisateur exécute python -o [APP], cela va entrainer la création du fichier .pyos s'ils n'existent pas encore. Cela va entrainer des écritures dans les logs.
 * 2. Si l'administrateur système exécute lui-même python -OO [APP], le fichier .pyos correspondant sera créer dans docstring. Des programmes nécessitent ces docstring pour fonctionner. Pour les exécutions à d'autres niveaux avec python -O [APP], python va utiliser le cache .pyos même si celui-ci est d'un niveau d'optimisation différent de celui-demander. L'unique facon de le corriger est de trouver le fichier .pyos et de le supprimer.

La méthode actuelle pour s'occuper des fichiers .pyo est de l'inclure comme il est, sans %ghosting.

Compilation Non Obligatoire
Depuis FC4 jusqu'au développement actuel, la compilation automatique des fichiers python sont effectués par brp-python-bytecompile qui compile tous les fichiers à l'extension .py. Ceci est indésirable pour les fichiers de programme dans %{_bindir} et %{_sbindir} car l'utilisateur ne pourra sans doute jamais exploiter ces fichiers, seul le fichier principal et python peut théoriquement utiliser ces fichiers mais cela est actuellement impossible à cause d'un bug. En attendant que ce problème se résolve, il y a deux solutions: %files %{_bindir}/orient.py %exclude %{_bindir}/orient.pyc %exclude %{_bindir}/orient.pyo
 * 1. Renommer le script dans %{_bindir} pour ne pas avoir d'extension .py: Par exemple: /usr/bin/orient.py vers /usr/bin/orient.
 * 2. Utiliser %exclude pour exclure les scripts concernés. Par exemple:

Plus d'informations sur ce bug est disponible à l'adresse: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182498