Les logiciels SIG Open Source sur Mac Os X: comment les installer, applications natives, Frameworks, Fink, MacPorts ou ... ?

Beaucoup de personnes se posent des questions lorsqu'ils veulent installer des logiciels SIG  Open Source sur Mac OS X.

Comment les obtenir ?

• à partir des Frameworks et des applications comme ceux de William Kyngesburye (www.kyngchaos.com/ mais, il y en a d'autres comme grass.bologna.enea.it/ ou openosx.com/grass/),
• les compiler
• ou les installer avec des gestionnaires de paquets comme Fink ou MacPorts ?
  

Quels sont les avantages et les différences entre toutes ces solutions ? Pour les premières, il faudra apprendre à utiliser un Terminal Unix (sur Mac, application dans Utilitaires), des shells comme bash (par défaut dans Terminal) et la notion de PATH Unix (variable d'environnement, chemins).

Rappel des caractéristiques Unix de Mac OS X

Rappelons tout d'abord que Mac OS X est un système Unix, tout comme Linux, mais basé sur un Unix BSD. En conséquence, il y a beaucoup de fichiers/dossiers Unix dans le système, mais ceux-ci sont masqués par défaut dans l'interface (Finder), par sécurité (les fichiers et dossiers en bleu clair dans la capture d'écran suivante):

Si l'on ne fait rien, des dossiers comme usr ne seront jamais visibles. Pourtant, sous Unix, l’installation des librairies tierces se fait généralement dans les dossiers comme /usr et /usr/local pour toutes celles qui ne sont pas natives du système. C'est le Filesystem Hierarchy Standard (« norme de la hiérarchie des systèmes de fichiers ») ou FHS des systèmes Unix. Sur ma machine:

                               /usr/local                                /usr/local/bin

Il est donc important d'avoir accès à ces dossiers ou de les rendre visibles. Pour cela, il y a plusieurs solutions:

• Choisissez « Aller/Aller au dossier » dans le Finder et tapez /usr, par exemple;
• Par le Terminal:

defaults write com.apple.Finder AppleShowAllFiles TRUE
killal Finder
et pour revenir à la normale
defaults write com.apple.Finder AppleShowAllFiles FALSE
killal Finder

• ou par le choix d'afficher tous les fichiers/dossiers à l'aide d'utilitaires comme Onyx ou Avosmacs2Visibility. L'option est réversible .

Comment maintenant installer les SIGs libres et/ou leur bibliothèque ?

Il y a plusieurs solutions que nous allons développer, de la plus complexe aux plus simples:

1) Compiler les sources

Pour cela, il faut installer les « Developper tools" ou XTools et le système X11 (c'est le standard  pour l'affichage graphique des applications sur la majorité des systèmes Unix tels que Linux, sur Mac OS X, c'est « Quartz » qui a été conçu par Apple pour remplir ce rôle). X11 (sur Mac, application dans Utilitaires) permet un portage plus facile des logiciels Unix vers Mac OS X. Ces éléments sont présents sur le/les DVD d'installation ou téléchargeables. Il est possible de choisir de les installer lors de l'installation standard ou de le faire par après. Avec eux, vous aurez alors tout ce qui est nécessaire pour compiler les sources avec, notamment, tous les compilateurs Unix.
 La démarche classique est alors, à partir du Terminal, et en se plaçant dans le dossier des sources:

./configure
./make
./sudo make install

sudo, car vous devez tenir compte des permissions Unix pour installer les choses et donc, avant de se lancer dans de telles démarches, une certaine connaissance est nécessaire. De plus, il est souvent nécessaire d'installer préalablement toutes les dépendances.
 

Les « Generic Mapping Tools » ou GMT ne s'installent que de cette manière (très facilement). SpatiaLite, GRASS GIS ou PostgreSQL/PostGIS peuvent aussi s'installer relativement aisément. Pour d'autres, comme QGIS, c'est moins évident. Autant préciser que plus le logiciel sera « lourd », plus ce sera compliqué et long, mais c'est une bonne école pour apprendre.

Les exécutables comme grass seront situés dans usr/local/bin et vous aurez besoin du Terminal ou de X11 pour les lancer. Il est aussi possible d'utiliser Automator pour créer une application    « double cliquable »:

.

2) Gestionnaires de paquets

Pour pallier à tous ces désagréments, il existe plusieurs systèmes de gestion de paquets comme Synaptic sur Ubuntu, ou autres.  Vous leur indiquez ce que vous voulez installer et ils s'occupent de tout (installation des dépendances préalables, configuration et compilation). Au final, vous obtiendrez des exécutables semblables à ceux obtenus dans la première solution, mais dans d'autres dossiers. Ceux-ci sont:

• Fink qui est le système de gestion de paquets de la distribution Linux Debian porté sur Mac OS X. Il installe les programmes dans un dossier à la racine du disque: /sw
• MacPorts (anciennement DarwinPorts) est un autre système qui installe aussi les programmes dans un dossier à la racine du disque: /opt
• Homebrew, le dernier venu et le plus prometteur d'après moi. Il respecte les FHS puisqu'il installe les programmes dans /usr/local/Cellar avec des liens symboliques dans usr/local/bin.

Tout est disponible avec ces solutions. Fink a quasi 12000 packages disponibles (pdb.finkproject.org/pdb/browse.php), MacPorts, quasi 8000 (www.macports.org/ports.php) et Homebrew, le plus jeune, quasi 1200 (github.com/mxcl/homebrew/tree/master/Library/Formula/ ). Une bonne connaissance des commandes Unix est aussi nécessaire pour les manipuler efficacement.

Une fois opérationnels, l'installation des logiciels se fait:

• soit à partir du Terminal:

sudo fink install grass (Fink)
sudo port install grass (MacPorts)
sudo brew install spatialite (Homebrew)

• soit à partir d'interfaces graphiques comme FinkCommander ou Porticus.

Il faut alors rajouter dans le PATH, /sw/bin, /sw/lib, /sw/include ou la même chose pour /opt 

Le problème est que le processus peut-être très long, puisque hormis Homebrew, ces systèmes vont installer énormément de choses nécessaires à leur fonctionnement, même si elles se trouvent déjà dans Mac OS X. Ce sont des projets qui créent des environnements autonomes (sw ou opt). Surgissent alors souvent des problèmes de comptabilité de bibliothèques entre ce qui se trouve dans /sw ou /opt et ce qui existe dans /usr ou /usr/local. En pratique, il faut devenir un as de la manipulation du PATH (sauf avec Homebrew)!

Les versions proposées ne sont souvent pas les dernières et Homebrew, le plus jeune, est beaucoup plus rapide. À titre d'exemple, l'installation des Mdb Tools, programmes permettant de traiter les fichiers Microsoft Access sous Linux, n'a pris que quelques minutes (je n'arrivais pas à les compiler par la première méthode). Ils permettent, entre autres choses, de transformer des geodatabases ESRI en fichiers SQLite/SpatiaLite (geospaced.blogspot.com/2009/12/converting-mdb-to-spatialite.html)

Tous les logiciels sont donc disponibles avec ces solutions, mais avec certains aléas et il est aussi possible d'utiliser Automator comme dans la première solution.

3) Les Frameworks

Pour faciliter le développement sous Mac OS X,  ses concepteurs ont introduit la notion de Frameworks. Un Framework est un dossier contenant du code, des headers, de la documentation et d’éventuelles ressources supplémentaires. Il est ainsi possible d’installer des librairies dynamiques en ne manipulant qu’un seul objet, le Framework. Ils permettent de gérer plusieurs versions d'une librairie (mise à jour) avec des liens symboliques. Par exemple sur mon Mac, j'ai deux versions de R installées et le contenu de /Library/Frameworks/R.framework est le suivant:

Les liens symboliques (marqués par des dossiers ou des fichiers avec des flèches) pointent vers la version utilisée 2.11 ou 2.12.

Les emplacements de ces Frameworks sont les dossiers Bibliothèque/Library (même si vous voyez Bibliothèque dans le Finder, ce sera Library dans le Terminal). Il y en a au moins trois:

• /Système/Bibliothèque, réservé à Mac OS X et auquel il ne faut pas toucher;
• /Bibliothèque, utilisable par les administrateurs et dont le contenu est destiné à être partagé par tous les utilisateurs;
• un dossier   ̃/Bibliothèque  par utilisateur qui peut y mettre ce qu'il veut.

R, par exemple, offre le choix d'installer ses Packages dans /Bibliothèque/Frameworks (disponibles pour tout le monde) ou dans   ̃/Bibliothèque (propres à un utilisateur donné).

Pour utiliser les binaires éventuellement présents dans ces Frameworks, il faudra ajuster le PATH, par exemple pour utiliser le SQLite/SpatiaLite de KyngChaos:

export PATH=/Library/Frameworks/SQLite3.framework/Programs:$PATH

La plupart des distributions de logiciels ou de librairies libres utilisent de plus en plus le système de Frameworks pour s'installer sur Mac OS X. Citons toutes les librairies de www.kyngchaos.com/ (GDAL etc.), QT, GTK+, R, Python de Python.org, ...

exemple sur mon Mac:

On peut aussi utiliser ce qu'il y a dans un Framework comme dépendances pour compiler d'autres librairies ou applications. Par exemple, le Framework GDAL a un dossier nommé unix qui contient tout ce qui est nécessaire pour créer une application qui utiliserait GDAL (tout comme s'il était dans /usr/local/...)

Par contre, certaines applications, même disponibles sous forme de packages (.pkg) comme PostgreSQL/PostGIS, s'installeront automatiquement dans /usr/local/pgsql du fait des dépendances.

4) Les Applications natives

La particularité des applications sous Mac OS X provient du fait que celles-ci sont en fait des dossiers (paquets), comme les Frameworks. Une application est un dossier qui se comporte comme un fichier, c’est-à-dire que l’on peut double-cliquer pour l'ouvrir. On peut aussi examiner et/ou utiliser ce qu'il y a dans ce dossier avec la commande « Afficher le contenu du paquet » disponible dans le menu contextuel du Finder. Voici, par exemple, le contenu de QGIS.app:  /Applications/QGIS.app/Contents (version KingChaos):

Cela permet à une application d’embarquer le code exécutable (fichier QGIS en noir) et toutes les ressources associées derrière une simple icône de fichier. Il est tout à fait possible de lancer l'application en ligne de commandes en se plaçant dans le dossier MacOS (voir figure précédente):

Vous verrez alors tous les plugins chargés par QGIS.app lors de son démarrage et les problèmes éventuels qui pourraient se poser (conflits avec l'un des plugins, par example).

Déplacer l’icône déplace donc l’intégralité de l’application. C'est la même chose avec GRASS GIS ou gvSIG (/Applications/gvSIG-1.9.app/Contents et /Applications/gvsig-oade-2010-1.0.0/gvSIG-OADE-2010.app/Contents):

Cette particularité peut pourtant s'avérer gênante pour les Linuxiens. En effet, si je veux, par exemple, utiliser le module qgis en Python, il ne sera pas dans /usr/... mais à l'intérieur de l'application elle-même dans /Applications/QGIS.app/Contents/Resources/python

et donc, pour l'utiliser dans Python il faut spécifier auparavant le chemin:

 ou  créer des liens symboliques ou un fichier .pth dans le dossier site-packages de Python. C'est ce que William Kyngesburye fait avec le module Python GDAL/OGR qui se trouve chez moi dans /Library/Frameworks/GDAL.framework/Versions/1.7/Python/site-packages. Le fichier gdal.pth contient donc:

import sys; sys.path.insert(0,'/Library/Frameworks/GDAL.framework/Versions/1.7/Python/site-packages')

GRASS GIS, QGIS, gvSIG, Spatialite-gui, Spatialite-gis, Ossim, LandSerf, ou OpenGeo Suite sont ainsi disponibles en applications autonomes.

Rien n'empêche qu'elles utilisent aussi des Frameworks comme dépendances. Cela permet, par exemple, de mettre à jour la version de GDAL dans le Framework GDAL, sans toucher ni devoir recompiler les applications qui l'utilisent comme GRASS GIS.

D'autres applications natives, comme OpenJump, ne sont pas  « enveloppées » dans des paquets. Il s'agit d'un simple exécutable qui se trouve dans le dossier bin du dossier OpenJump. Il fera appel à tout ce qui est dans le dossier (lib etc.).

Les applications vont rarement toucher à ce qui est à l'intérieur de leur dossier, à l'exception notable de gvSIG où il faut placer les extensions dans /Applications/gvSIG-1.9.app/Contents/Resources/Java/gvSIG/extensiones ou  /Applications/gvsig-oade-2010-1.0.0/gvSIG-OADE-2010.app/Contents/Resources/Java/gvSIG/extensiones. Ceci pose de nombreux problèmes pour l'installation d'extensions supplémentaires. Une solution est donnée dans  gvsig.org/plugins/downloads/hack-for-installing-mac-os-x-non-supported-gvsig-extensions . A l'opposé QGIS va installer les plugins supplémentaires dans un dossier .qgis situé dans votre dossier utilisateur /Users/vous/.qgis (. donc fichier caché):

 

et non dans /Applications/QGIS.app/Contents/plugins (ça ne sert strictement à rien de les placer dans ce dossier, réservé aux extensions livrées avec QGIS.app).

Conclusions

Et voilà, j'espère que ces explications n'auront pas un caractère trop complexe. Vous avez maintenant le choix.

Pour ma part, j'utilise exclusivement les Frameworks et applications natives, sauf exception. En effet, lorsque quelque chose ne figure pas dans ces possibilités, je tente de les compiler par moi-même ou j'utilise Homebrew, beaucoup plus rapide et respectant mieux les caractéristiques de Mac OS X, et non Fink ou MacPorts, beaucoup plus lourds. Je ne comprends toujours pas bien pourquoi certains s'obstinent à utiliser ces deux derniers systèmes lorsqu'il existe une solution native (dans les autres cas, rien à dire, je les utilise aussi, quitte à les éliminer lorsque je trouve une version native).

Le cas de Python est significatif: il y a une version intégrée au système et il y a la possibilité d'installer des versions natives différentes depuis le site  www.python.org/download/  (sous forme de Framework, il n'y a que le PATH à changer pour les utiliser en lieu et place du Python standard). Pourquoi alors vouloir absolument  réinstaller une autre version de Python en utilisant Fink ou MacPorts ? Je connais certains « acharnés » , qui ne jurent que par ces systèmes, et s'étonnent ensuite d'avoir des problèmes avec la version Python installée nativement. Il est vrai que certains modules comme PyGTK sont difficiles à installer avec le Python du système, mais... 

 

Site officiel : Terminal (Mac OS X)
Site officiel : La variable d'environnement PATH
Site officiel : X11 (Mac OS X)
Site officiel : Onyx
Site officiel : Avosmacs2Visibility
Site officiel : Automator
Site officiel : Generic Mapping Tools (GMT)
Site officiel : Fink
Site officiel : MacPorts
Site officiel : Homebrew
Site officiel : FinkCommander
Site officiel : Porticus
Site officiel : KingChaos, applications et Frameworks
Site officiel : MDB Tools