| View previous topic :: View next topic |
| Author |
Message |
341438
n00b
Joined: 01 May 2015
Posts: 47
|
 Posted: Tue Aug 04, 2015 2:09 pm Post subject: [ebuild] Python et la variable PYTHON_USEDEP (résolu) |
 |
|
Salut tout le monde,
je suis en train de mettre à disposition mes ebuilds et j'essaie de les améliorer. J'ai mis
à disposition un programme python et en m'inspirant d'autres ebuild, j'ai découvert la variable
PYTHON_USEDEP. J'ai bien vu qu'on en parle sur le wiki, mais ça ne m'aide pas, je n'ai pas
encore bien compris à quoi elle sert.... certainement le manque d'expérience en python!
Pour être clair, j'ai regardé le paquet pafy:
http://gpo.zugaina.org/dev-python/pafy
C'est le deuxième qui m'intéresse, il contient la ligne suivante:
| Code: | | DEPEND="test? ( dev-python/nose[${PYTHON_USEDEP}] )" |
Je me pose la question suivante: à quoi sert PYTHON_USEDEP pour savoir quand je devrai moi aussi le mettre.
Après des recherches, ma supposition est la suivante. Dans ce cas, si le USE flag test est activé, on doit installer
la dépendence dev-python/nose. Il se peut que plusieurs versions de pythons soient installées sur une machine. Par exemple,
j'ai la version 2.7 et 3.4 sur mon système. Si je regarde la valeur dans mon cas à l'aide d'un "echo $PYTHON_USEDEP" dans un ebuild,
j'obtiens:
| Code: |
python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-)
|
Donc je devine que ça ajoute des use_flags du type "python_targets_python3_3. Toutefois, le use flag est par exemple:
| Code: | | python_targets_python2_7(-)? |
Et là je ne suis pas sûr de l'interprétation: cela ressemble à ce qu'il y a sous https://devmanual.gentoo.org/general-concepts/dependencies/,
dans la partie "Built with USE Dependencies". J'en arrive à la conclusion suivante: si le USE flag python_targets_python2_7 n'est pas présent, c'est qu'il n'est pas activé. Si on avait mis un
(+), cela signifierait que son absence signifie que ce USE flag est activé. Le hic, c'est que ce use flag est très peu utilisé. Même en remontant à la base des dépendance,
j'ai de la peine à trouver un paquet qui l'utilise. Il me semble que setuptools fait partie de la base, toutefois il n'a pas de use flag du type python_targets_python2_7.
Bon dans tout ça, cela doit être une information pour qu'une dépendance soit installée pour le bon interpréteur python ou quelque chose dans ce genre. En effet, selon la version de python installée, on
doit installer dans un répertoire différent.
Bref, vous aurez compris que ce n'est pas clair dans ma tête. Quand cela le sera, je pourrai écrire de meilleures ebuilds.
Je laisse la place aux spécialistes à présent 
Last edited by 341438 on Thu Aug 06, 2015 12:58 pm; edited 1 time in total |
|
| Back to top |
|
 |
boozo
Advocate
Joined: 01 Jul 2004
Posts: 3193
|
| Posted: Tue Aug 04, 2015 9:54 pm Post subject: |
|
|
'alute
avec de bonnes recherches et lectures couplées à une bonne logique déductive quoi dire de plus ? 
Sans trop m'avancer, je crois simplement pouvoir dire qu'il y a - surtout - une dimention temps(/historique) à considérer concernant les useflags et variables ayant traits à python.
Les uses python_target_{x} et python_single_target_{y} sont les plus récents (cf. ENEWS du 2012-11-06 "PYTHON_TARGETS deployment") et sont un peu particuliers car ils définisent le(s) interpréteur(s) python souhaité(s) et activés de manière globale pour le système. C'est pourquoi on ne les vois pas en temps que tels dans les ebuild car ils sont normalement gérés via le profile utilisé (càd juste pour infos encore un ensemble de variables/paramétrages prédéfinis par les devs gentoo dans le but de fournir un environnement "propre"(/fonctionnel) dédié à un usage/besoin donné i.e. un environnement serveur pour une architecture spécifique ; la même chose pour un desktop avec une composante sécuritaire type "selinux" ; etc)
Pour l'histoire donc, au fil du temps, on a vu fleurir une forme de versionning des useflags python2-7 puis python3-x, python3_y du fait de la non rétro-compatibilité des abi entre elles. Et on peu rajouter qu'il avait déjà un "python" que l'on trouve encore aussi (lui est plus ancien et beaucoup moins homogène d'un package à l'autre en termes de fonctions)
| Code: | $ quse -D python
global:python: Add optional support/bindings for the Python language
(...)
local:python:app-office/gnumeric: Enable python plugin loader.
local:python:app-vim/vim-latex: Enable python support which can help speed up some functionality
local:python:dev-qt/qt-creator: Enable Python source code editor
(...) |
Enfin si on ajoute à celà le fait que d'autres interpréteurs python existent et peuvent être souhaités par l'utilisateur (i.e. pypy ; jython ; etc) eux-même potentiellement souffrant des mêmes troubles de compatibilité, cela signifia d'autres useflags (i.e. pypy2_x ; pypy3_x ; jython2_y etc) et ... cela est devenu alors un peu ardu a comprendre ; pour ne pas dire a gérer pour nous tous 
| Code: | $ quse -D pypy
python_targets:pypy: Build with PyPy
python_single_target:pypy: Build for PyPy only
$ quse -D python3_2
python_targets:python3_2: Build with Python 3.2 (deprecated)
python_single_target:python3_2: Build for Python 3.2 only (deprecated)
|
Donc voilà le temps à passé et les conventions d'usages et de nommages des devs ont fait que - de façon non exhaustive - :
°) le package manager portage reste validé par les devs gentoo pour fonctionner avec l'interpreteur fournit par dev-lang/python (en version 2.7 et/ou 3.4 désormais cf. ENEWS du 2015-07-25 "Python 3.4 enabled by default") ainsi que pour l'ensemble des programmes nécessitant python ou ayant besoin de son support, d'un connecteur pour, etc.
Ceci est (doit être) géré par les 2 variables $PYTHON_TARGETS et $PYTHON_SINGLE_TARGETS (*) depuis le make.conf donc et peuvent ainsi surcharger le profil qui définit déjà cela par défault ; ceci afin d'avoir un système fonctionnel sans paramétrage de l'utilisateur à l'installation.
°) L'opérateur "-" reste bien entendu utilisé de façon classique aux useflags pour la désactivation du support concerné s'il y a lieu (aucun opérateur "+" n'est utilisé en guise d'activation car c'est implicite de l'action même que de définir un useflag)
La gestion du module python utilisé reste réalisée au quotidien par #eselect en gestion courante et #python-updater lors d'un upgrade.
°) et si j'ai compris tous les différents "python's usesflags" antérieurs des ebuild sont proscrits au profit de la variable $PYTHON_USEDEP ce qui en simplifie leur maintenance (cf. voir la doc des eclass correspondants)
°) le use "python" originel, resté dans son jus, est du ressorts de la gestion "classique" des useflags càd via la variable $USE du make.conf pour un support global ou en spécifique par packages via package.use ; utiliser l'un et/ou l'autre des stratégies de gestion est - comme il se doit chez nous - laissé à l'appréciation de l'utilisateur selon son besoin propre
(*) n.b. Avant qu'on m'en parle... oui, il existe aussi une 3ème variable d'usage encore similaire au 2 premières ($PYTHON_USE) mais celle-ci doit être considérée comme obsolète si si ^^
Edit: Il est tard, il fait chaud, donc j'espère ne pas en avoir écrit de trop grosses et dans tous les cas vous génez pas pour ajuster et compléter
Edits: typos, typos, etc
_________________
" Un psychotique, c'est quelqu'un qui croit dur comme fer que 2 et 2 font 5, et qui en est pleinement satisfait.
Un névrosé, c'est quelqu'un qui sait pertinemment que 2 et 2 font 4, et ça le rend malade ! "
Last edited by boozo on Wed Aug 05, 2015 10:54 pm; edited 1 time in total |
|
| Back to top |
|
|
341438
n00b
Joined: 01 May 2015
Posts: 47
|
| Posted: Wed Aug 05, 2015 1:01 pm Post subject: |
|
|
Merci pour cette longue explication!
Le rappel historique était très intéressant et permet de mieux comprendre les choses.
J'ai relu la description de la variable PYTHON_USEDEP et je crois que c'est enfin passé!
Si je résume: si un paquet dépend de librairies python, on utilise PYTHON_USEDEP pour s'assurer que ces librairies soient utilisables
avec les différentes versions. Par exemple si j'ai python 2.7 et python 3.4, en utilisant PYTHON_USEDEP, les librairies python installées le seront
pour python 2.7 et python 3.4. Donc de manière générale, on doit toujours l'utiliser.
Juste ? |
|
| Back to top |
|
|
boozo
Advocate
Joined: 01 Jul 2004
Posts: 3193
|
|
| Back to top |
|
|
341438
n00b
Joined: 01 May 2015
Posts: 47
|
| Posted: Thu Aug 06, 2015 12:58 pm Post subject: |
|
|
Oulala..... j'ai l'impression de me noyer. Bon j'ai envie de finir cet ebuild, donc je vais faire le changement comme je pense et selon
ce que tu as dit.
Ensuite je vais stopper le tout et il faut que je relise tout ça. EAPI et eclass ne sont pas très clairs dans ma tête. Je ne peux pas
continuer sans avoir bien compris le système. Merci pour le lien, je pense qu'il m'aidera à tout mettre en place. Dans une semaine,
ça ira mieux
Merci pour tout!  |
|
| Back to top |
|
|
boozo
Advocate
Joined: 01 Jul 2004
Posts: 3193
|
| Posted: Thu Aug 06, 2015 2:35 pm Post subject: |
|
|
| Tristelune wrote: | Oulala..... j'ai l'impression de me noyer. Bon j'ai envie de finir cet ebuild, donc je vais faire le changement comme je pense et selon
ce que tu as dit. |
Naan mais c'est bon hein, t'inquiètes pas trop non plus (j'ai édité mon précédant message car c'était peut-être confusant écrit comme ça tout à la suite)
L'EAPI c'est juste l'API propre à "gentoo" en fait et on est en version 5 ; et une Eclass est une simple bibliothèque de méthodes (comme en java i.e.) et par "héritage" lorsqu'on la déclare, on peut employer ses méthodes et variables prédéfinies.
Si tu t'appuis sur des ebuilds pour modèles, selon les cas, je l'ai indiqué pour comprendre le parallèle avec la classe python des api antérieures qui peuvent encore se voir çà et là sinon que les nouveaux standards peuvent encore se voir mal appliqués ; aussi m'a-t-il semblé les exemples de formalisme et d'emploi assez clairs pour comprendre un peu mieux les choses.
Et puis tu n'es pas non plus obligé de tout saisir dans ses moindres détails d'un coup avant de faire quoi que ce soit... Il faut expérimenter, se tromper, chercher à comprendre, ré-essayer, etc (i.e. je patauge toujours gaillardement depuis un bail mais j'arrive à faire quelques trucs qui fonctionnent - par erreur - de temps à autres  )
_________________
" Un psychotique, c'est quelqu'un qui croit dur comme fer que 2 et 2 font 5, et qui en est pleinement satisfait.
Un névrosé, c'est quelqu'un qui sait pertinemment que 2 et 2 font 4, et ça le rend malade ! " |
|
| Back to top |
|
|
341438
n00b
Joined: 01 May 2015
Posts: 47
|
| Posted: Sat Aug 08, 2015 7:48 am Post subject: |
|
|
| boozo wrote: |
L'EAPI c'est juste l'API propre à "gentoo" en fait et on est en version 5 ; et une Eclass est une simple bibliothèque de méthodes (comme en java i.e.) et par "héritage" lorsqu'on la déclare, on peut employer ses méthodes et variables prédéfinies.
|
Ok, je pensais aussi que ce ne doit pas être trop compliqué. Ca clarifie déjà un peu les choses!
| boozo wrote: |
Et puis tu n'es pas non plus obligé de tout saisir dans ses moindres détails d'un coup avant de faire quoi que ce soit... Il faut expérimenter, se tromper, chercher à comprendre, ré-essayer, etc (i.e. je patauge toujours gaillardement depuis un bail mais j'arrive à faire quelques trucs qui fonctionnent - par erreur - de temps à autres ) |
Merci pour ce commentaire qui m'a bien faire rire . Comme tu as de l'expérience, je pense toutefois que tu dois fréquemment faire des erreurs .
Pour ma part j'accepte aussi les tours de magie. Parfois lorsque je trouve la commande miracle qui résoud tous mes problèmes, je l'exécute sans poser
plus de questions. J'y reviens ensuite plus tard pour essayer d'approfondir. C'est un système qui fonctionne pas mal, c'est l'expérimentation dont tu parlais. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
French
