Une cale est une petite bibliothèque qui intercepte et modifie les appels vers une autre bibliothèque, principalement pour faciliter la compatibilité.
La maintenance de plusieurs versions d’une bibliothèque est nécessaire pour prendre en charge vos clients. Les bibliothèques Shim traduisent les appels de l’ancienne à la nouvelle bibliothèque avant de les transférer vers la nouvelle bibliothèque.
Exemple 1 :
Les installations Linux sont normalement livrées avec une seule version Ruby. Les développeurs Ruby doivent avoir différentes versions de Ruby sur leurs nombreux projets actifs. Rbenv utilise des cales pour résoudre ce problème.
Exécuter une commande Ruby sous Linux signifie rechercher l’exécutable dans le chemin – qu’il recherche de gauche à droite. Ainsi, l’exécution de la commande Ruby rails server
signifie que Linux trouve et exécute Rails, un exécutable Ruby, dans le premier répertoire.
Rbenv ajoute un répertoire shims
et le charge avec des scripts de cale avant d’ajouter le chemin. Il existe un script de cale pour chaque application Ruby et exécuter une application Ruby signifie maintenant exécuter le script de cale correspondant. Ainsi, l’exécution de rails signifie exécuter le script Rails dans le répertoire shims
et non l’application Rails dans usr/local/bin
. Le script élabore la version Ruby requise, puis exécute son application correspondante, dans ce cas Rails, sous cette version Ruby attendue.
Exemple 2:
Microsoft utilise des cales pour simuler les appels Windows d’une application. Lorsqu’une application effectue un appel système, elle passe par la » Table d’adresses d’importation « .
Vous pouvez changer la table et remplacer l’appel Windows par un appel à une cale. La cale dans l’exemple est une cale ’version-lie’. L’application pense qu’elle est sur une machine Windows 7.