Pourquoi py et pas pyc ou pyo?

Lorsque j'installe un paquet deb python, disons que python-numpyles fichiers sont des fichiers python simples. Comment puis-je dire au gestionnaire de paquets - que je préfère en fait utiliser pyc ou encore mieux - les fichiers pyo?

package-management python

— Adobe
source

Vous les avez déjà et vous les utilisez déjà

Des applications Python bien packagées sont en cours de compilation dans des .pycfichiers dans un script exécuté après l' installation des fichiers. Ceci est nécessaire selon les directives de packaging pour pouvoir adopter l'installation Python que vous utilisez à ce moment. N'oubliez pas que les .pycfichiers sont très spécifiques à votre système (version Python et dépendances).

Tous .pyoet les .pycfichiers sont donc spécifiquement exclus des packages et étiquetés comme des erreurs par Lintian :

Les fichiers source python compilés ne doivent pas être inclus dans le package. Ces fichiers doivent être supprimés du package et créés lors de l'installation du package dans le postinst.

Reportez-vous à la section 2.6 de la politique Debian Python ( Compilation d'octets des modules ) pour plus de détails.

Gravité: grave, Certitude: certaine

Dans le cas de python-numpycette compilation d'octets post-installation est gérée par le crochet debhelper de pycentral. Après l'installation, cela ressemble à ceci:

ls -l /usr/lib/python2.7/dist-packages/numpy
lrwxrwxrwx  1 root root     47 Mar 20  2012 add_newdocs.py -> ../../../../share/pyshared/numpy/add_newdocs.py
-rw-r--r--  1 root root 251912 Aug  6 22:06 add_newdocs.pyc

Quelques informations supplémentaires

La raison pour laquelle ces fichiers .pyc/ .pyone sont pas compilés au moment de l'exécution lors du premier démarrage de l'application, comme prévu, est la suivante.

Les fichiers Python sont installés dans un répertoire à l'échelle du système, disponible pour tous les utilisateurs du système. Chaque fois qu'un utilisateur démarre l'application, l'interpréteur Python peut lire les .pyfichiers, mais il ne peut pas écrire dans les répertoires (par exemple /usr/lib/python2.7/dist-packages/). Cela fait partie de la sécurité générale de tous les systèmes Linux; les utilisateurs ne devraient pas écrire sur /usr, seulement avec les droits root cela devrait être possible. Pour cette raison, les hooks APT compileront les fichiers Python pour vous au moment de l'installation; d'une part pour minimiser la taille du paquet, d'autre part pour pouvoir redéclencher les hooks une fois que quelque chose change sur votre système concernant Python, car il est nécessaire de recompiler quand ils deviennent incompatibles lors des mises à niveau par exemple.

Cela n'affectera cependant pas les fichiers python appartenant à l'utilisateur en cours de compilation.

— gertvdijk
source

Je devrais donc me rendre /usr/share/pyshared/accessible en écriture - afin de permettre à python de compiler des fichiers lors de la première exécution.

— Adobe

@Adobe Quoi? non! Ne rendez jamais ces répertoires système accessibles en écriture pour les utilisateurs. Votre gestion de paquets les a déjà compilés pour vous (selon ce que j'essayais de dire dans ma réponse). Maintenant mis à jour pour être plus clair à ce sujet.

— gertvdijk

Vous maintenant - que je viens de regarder /usr/lib/python2.7/dist-packages/numpy- il y a des pycfichiers. Je me souviens que j'ai regardé là-bas sur plusieurs installations - et il n'y avait que des fichiers py simples. Donc je sorte de "ne peut pas reproduire le bug".

— Adobe

La seule raison pour laquelle le .pycne serait pas encore là est que le paquet n'a pas été complètement installé. Après le déballage, il y a d'autres étapes à suivre. IIRC le hook python-central n'est exécuté qu'après l'installation de tous les packages. Ainsi, lors d'une session APT en cours ou interrompue lors de l'installation du package, l'observation que vous avez décrite peut probablement être faite.

— gertvdijk