J'en pense que je n'ai pas tout compris, mais que ça semble assez complexe pour assez peu.
Après, chacun ses façons de bosser : si lui ça lui va, tant mieux pour lui.
D'ailleurs, à ce sujet (chacun ses façons de bosser), j'envisage (enfin) de passer sérieusement à Python3/GTK3⁽¹⁾, et donc j'aimerais bien en profiter pour me refaire un répertoire de travail propre. Dans l'idéal, j'aimerais bien que le dépôt ressemble à quelque chose comme ça :
seth@fadreils: tmp$ ls -RFi elzapps/
elzapps:
54928 build.sh*
57471 firstapp/
55880 license
54225 readme
56070 secondapp/
55073 thirdapp/
elzapps/firstapp:
58462 elzlibs/
57234 firstapp.py*
55880 license
56169 readme
elzapps/firstapp/elzlibs:
58586 firstlib.py
58522 __init__.py
60832 secondlib.py
elzapps/secondapp:
58093 elzlibs/
55880 license
58069 readme
59911 secondapp/
elzapps/secondapp/elzlibs:
58522 __init__.py
60832 secondlib.py
61722 thirdlib.py
elzapps/secondapp/secondapp:
61050 __init__.py
61018 __main__.py*
61096 specificlib.py
elzapps/thirdapp:
59390 elzlibs/
55880 license
59226 readme
62665 resources/
60066 thirdapp/
elzapps/thirdapp/elzlibs:
58586 firstlib.py
58522 __init__.py
61722 thirdlib.py
elzapps/thirdapp/resources:
63709 somefile
elzapps/thirdapp/thirdapp:
61257 __init__.py
62084 __main__.py*
60184 specificlib.py
seth@fadreils: tmp$
Donc avec un répertoire principal contenant quelques fichiers méta⁽²⁾, et ensuite, un répertoire par appli, contenant à chaque fois un module/package python contenant le code de l'appli proprement dite, quelques fichiers supplémentaires pour l'appli elle-même, et un package python contenant les bibliothèques communes. Ce dernier ne contiendrait que les bibliothèques utilisées par l'appli en question, avec des liens physiques pour que ce soit le même fichier partout où il y en a besoin.
En gros, les avantages que j'y vois:
- Ça facilite les MàJ des biblis communes, puisque « ls elzapps/*/elzlibs/machin.py » indique directement quelles applis utilisent une bibli donnée, et en cas de modif impactant plusieurs applis, ça fait un seul commit pour les corrections.
- Si je veux proposer une appli particulière à quelqu'un, pas besoin de lui faire cloner tout le dépôt dont la grosse majorité ne servira pas, il y a juste à récupérer le répertoire de l'appli en question, et toutes mes dépendances à moi sont dedans.
Vous savez s'il existe un gestionnaire de versions qui permet de bosser facilement de cette manière ? Git a l'air d'avoir un peu de mal avec les liens physiques, et je ne suis pas sûr qu'il soit très permissif sur la partie « récupérer seulement un répertoire du dépôt » (Ça, SVN y arrive, mais SVN, quoi. Même avec mon utilisation on ne peut plus basique du truc, le côté décentralisé de git est largement plus pratique).
Alternativement, si, ce qui est probable, vous voyez des failles majeures dans cette façon de travailler et avez des suggestions pour rendre le tout plus propre, je suis disposé à écouter, hein 🙂
(1) En lisant
le rapport de bug de Clearlooks-Phenix, j'suis tombé vers un lien pour un thème issu de Mate qui est à peu près regardable (ça fera une bonne base de travail pour commencer à me faire un truc correct, dirons-nous). En espérant qu'on ait un peu de temps avant la prochaine MàJ qui cassera tout -_-
(2) Le script build.sh, notamment, sert à compiler si besoin, et à faire une arbo commune pour ne pas avoir quinze tonnes de reps à ajouter dans $PATH et $PYTHONPATH. Sinon, le fichier licence est lui aussi lié physiquement dans tous les répertoires, vu que c'est la GNU GPL v3 dans tous les cas.
