====== Commit 2016-08-18 ======

Je débute l'explication de ce commit qui porte sur le module ''linuxbin'' en rappelant d'où vient ce module et ce qu'on veut en faire plus tard.

===== Historique de linuxbin =====

Le module ''linuxbin'' tire son nom du fait qu'il contient les utilitaires et fichiers de configuration du répertoire ''~/bin'' sous les machines Linux. 

Concernant **les fichiers de configuration**, ''linuxbin'' permet d'être certain que tout le monde possède toujours le même environement de travail (variables d'environement principalement) pour une machine donnée. Par exemple, quand une nouvelle version de MATLAB est installée sur une machine, le ''PATH'' doit être adapté chez tout le monde. Il suffit alors de modifier ''linuxbin'' et de demander à tout le monde de mettre à jour son ''~/bin'' via un ''svn update'' pour régler le problème.

Concernant **les utilitaires**, il s'agissait initialement de petits scripts dont tout le monde a besoin sous Linux pour travailler avec Metafor (lancer un calcul ou une batterie). Au cours du temps, ces scripts ont grossi et ont tellement évolué qu'on n'imagine plus travailler sans eux! Aujourd'hui, ''comp.py'' permet de d'effectuer un checkout des sources Metafor, compiler, lancer une batterie et envoyer les résultats par e-mail. De manière similaire ''launch.py'' permet de lancer un calcul Metafor sur un serveur (simple PC ou cluster) avec notifications par e-mail et gestion éventuelle des queues batch et disques locaux.

Ces scripts sont tellement utiles qu'ils sont maintenant intégrés aux versions distribuées de Metafor (Techspace). En pratique, pour nous, il faut depuis peu faire un checkout de ''linuxbin'' à côté des sources de Metafor (''oo_meta'' et ''oo_nda'').

Le module ''linuxbin'' peut être également intéressant pour n'importe quelle personne utilisant les machines qui y sont configurées (nic4 ou les autres machines du CECI). Par exemple, Dominik utilise ''linuxbin'' alors qu'il n'utilise pas encore Metafor. D'autres thésards, dans d'autres services,  pourraient utiliser ''linuxbin'' (Kim Liégeois, David Thomas).

Enfin, de plus en plus de personnes développent du code hors de Metafor. Le module ''linuxbin'' pourrait contenir le code commun à tous ces codes pour qu'ils restent compatibles entre eux. Il pourrait également aider à partager certaines classes de base (interface BLAS, TBB, timers, gestion des streams, solveurs externes, etc.) et certains modules de base (batterie de tests, ''CMakeLists.txt'', lancement de processus multiples sur cluster, etc.)

En conclusion, ''linuxbin'' doit être rendu public. **Il doit devenir accessible à n'importe qui voulant travailler sur nos machines ou avec nos libs ou avec nos codes**. C'est dans ce but que le repository ''linuxbin'', anciennement dans le repository SVN de Metafor a été transféré sur [[https://github.com/ulgltas/linuxbin|github]].

===== linuxbin sur github =====

Le repository SVN a été converti en un repository git et envoyé sur github dans l'organisation "ulgltas" que j'ai créée. Cette organisation permet de gérer les permissions d'accès aux différents codes. Elle contient actuellement "waves", "linuxbin", "ceci" (les tutos du CECI) et 2 forks ("pfem" de Marco et "plotter2d" de Yves). C'est à cet endroit que je compte mettre les autres codes open source qu'on va créer (gen4?, geniso?).

Pour récupérer un repository public de github, il n'y a pas besoin de compte github. Un simple "git clone" anonyme suffit.
  git clone https://github.com/ulgltas/linuxbin.git ./bin
Néanmoins, si vous voulez un jour commiter des modifs, il vous faudra un compte. Je vous conseille donc de créer un compte github et je vous ajouterai dans les développeurs ulgltas. Ca vous permettra de faire des ''git push''.

===== comp.py =====

Le script ''comp.py'' a été modifié pour pouvoir gérer ''linuxbin'' en plus de ''oo_meta'', ''oo_nda'' et ''parasolid'' lors de la compilation de Metafor.

J'ai profité de cette amélioration du script pour nettoyer un peu ce code. En particulier:
  * j'ai supprimé la possibilité de spécifier les repositories dans les paramètres. Il y en a maintenant 3 différents et ils doivent être que très rarement changés (1 pour oo_meta et oo_nda - 1 pour parasolid et 1 pour linuxbin).
  * j'ai supprimé la possibilité de baconniser sur une machine annexe. Ce code était assez vieux, non testé, relatiement complexe. De plus, il appelait une fonction ''battery.py baconnize'' qui n'existe plus. 
  * j'ai fait qq modifs de forme "interractif" => "interactive".
  * j'ai renommé certaines options: ''BUILD_OPT'' => ''CMAKELIST''.

<note important>En conséquence, les anciens fichiers de config (''comp.cfg'') ne sont plus utilisables. Supprimez-les avant de relancer un nouveau ''comp.py''.</note>

===== Migration vers linuxbin de github =====

Migrez d'abord tous vos ''~/bin'':
  ssh blueberry
  rm -r bin
  git clone https://github.com/ulgltas/linuxbin.git ./bin
et ceci pour chaque machine (blueberry, spring, thorgal et fabulous)

Si vous avez des working-copies de Metafor qui utilisent ''linuxbin'' sous SVN, faites pareil:
  cd dev
  rm -r linuxbin
  git clone https://github.com/ulgltas/linuxbin.git
Et voilà, vous avez migré...

===== Développement linuxbin =====

Si vous ne voulez pas modifier ''linuxbin'', votre lecture s'arrête ici. 

Si vous voulez modifier ''linuxbin'':
  - Créez vous un compte github.
  - Dites-le moi et je vous inclus dans [[https://github.com/orgs/ulgltas|l'organisation ulgltas]] ansi que dans une ou des [[https://github.com/orgs/ulgltas/teams|équipes]].
  - Je vous conseille alors d'[[https://github.com/settings/keys|associer une clef SSH]] à votre compte. Ca va vous permettre de travailler de manière aussi simple avec github qu'avec nos machines (sans passwd). La clef à envoyer est votre clef publique des stations.
  - Le clone ssh peut se faire via la commande: (login=git, pas votre username!)

   git clone git@github.com:ulgltas/linuxbin.git

A ce moment, vous avez (et c'est le problème majeur de git), 100000 manières pour travailler:

==== Manière 1 (à la SVN) ====

  - vous modifiez le source et faites des commits locaux sur une machine donnée.
  - une fois que vous voulez publier vos modifs sur github, vous faites un ''git pull'' (équivalent de ''svn update'' pour être sûr d'être à jour), puis ''git push origin master''.

Cette manière n'a pas d'intérêt par rapport à une procédure SVN. C'est du SVN mais avec plus de commandes. Le seul intérêt est d'avoir l'interface web de github. Elle est aussi la plus simple.

==== Manière 2 (à la github) ====

  - vous faites un "fork" de ''linuxbin'' sur votre compte github personnel (il suffit de cliquer sur le bouton "fork" en haut à droite à partir de https://github.com/ulgltas/linuxbin)
  - vous clonez alors votre copie de ''linuxbin'' et vous la modifiez autant que vous le voulez (''git add'', ''git commit'', ''git push'')
  - une fois que vous voulez partager vos modifs avec le reste du groupe, vous faites un **"pull request"**. Github a en effet mémorisé le fait que votre repository est une copie d'un autre et vous permet de demander un pull vers le repository parent.

C'est la manière qu'à choisi Dominik (cfr https://github.com/dboemer/linuxbin). C'est aussi la manière la plus "open source" de faire. Elle permet a des inconnus de modifier un repository auquel ils n'ont pas accès en écriture. Autrement dit, pour reprendre l'exemple de Dominik, il n'a pas besoin d'être un membre de l'organisation ulgltas pour modifier ''linuxbin''. Ses modifications sont envoyées pour analyse aux membres de l'organisation qui acceptent le "pull request" après une éventuelle discussion et des corrections itératives.

L'inconvénient est la lourdeur du procédé. Par exemple, aujourd'hui, Dominik doit synchroniser son fork avec les modifs que je viens de faire via les commandes:
  git remote add upstream https://github.com/ulgltas/linuxbin.git
  git fetch upstream
  git rebase upstream/master
Bref, je ne conseille pas cette méthode à ceux qui ne veulent pas s'impliquer un peu dans l'apprentissage de git/github.

==== Méthode 3 (branche) ====

Cette manière est utilisable avec SVN mais peu recommandée vu le manque de robustesse des algos de fusion de branche de SVN.

L'idée est donc de créer **une branche de dévelopement** à son nom et de commiter dans celle-ci tant que les modifs ne sont pas finalisées. Une fois que les modifs sont OK, il suffit alors de fusionner (''git merge'') la branche personnelle à la branche maître (''master'').

C'est ici, pour moi, qu'on obtient un vrai intérêt de github sur SVN (ou du moins sur la manière dont nous utilisons SVN pour Metafor).

En d'autres mots:
  * récuperation d'une working copy:

  git clone git@github.com:ulgltas/linuxbin.git
  
  * création d'une branche / envoi de la branche sur github

  git checkout -b romain
  git push -u origin romain

  * modif du code / commits dans la branche

  git add .
  git commit -m "commit 1"
  git add .
  git commit -m "commit 2"
  git push origin romain

  * merge de la branche avec master

  git checkout master
  git merge romain

Ce système me semble être un bon compromis entre la méthode 1, qui ressemble à du SVN en moins pratique, et la méthode 2 qui nécessite des synchronisations dans tous les sens et une duplication des repositories.
C'est la méthode que je vais essayer d'appliquer.

Quoiqu'il en soit, si vous avez des idées, ou des remarques, n'hésitez pas à m'en parler. Comme dit plus haut, j'aimerais à terme mettre plusieurs projets sur github pour les rendre accessibles à n'importe qui (le mailleur gen4 en particulier). Ils seront donc gérés par git et non plus par SVN. Il est donc important de trouver une manière simple de travailler avec git pour le futur de Metafor.

 --- //[[r.boman@ulg.ac.be|boman]] 2016/08/18 13:18//