'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: Select all
$ 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: Select all
$ 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
)