Gestion des dépendances avec Merb

Utilisant de plus en plus Merb sur mon temps personnel et dans mes projets open source, j'ai dû étudier un peu plus profondément le système de dépendances de Merb.

Merb est par essence un framework basé sur les gems. Dans cette logique il pousse à n'utiliser que des gems et uniquement ceux ci.

Utilisation des gems avec Merb

Pour utiliser un gem avec Merb, rien de plus simple car tout est prévu pour. Que ce soit avec votre répertoire local de gem ou alors avec un freeze du gems.

Utilisation de votre répository gem local

Si vous ne voulez utiliser que cette technique, alors rien de plus simple, modifier le fichier /config/dependencies.rb pour indiquer les gems à charger dans votre application. Voici par exemple le fichier dépendencies.rb d'une application installer de frais.

# dependencies are generated using a strict version, don't forget to edit the dependency versions when upgrading.
merb_gems_version = "1.0.7.1"
dm_gems_version   = "0.9.8"

# For more information about each component, please read http://wiki.merbivore.com/faqs/merb_components
dependency "merb-action-args", merb_gems_version
dependency "merb-assets", merb_gems_version  
dependency "merb-cache", merb_gems_version   
dependency "merb-helpers", merb_gems_version 
dependency "merb-mailer", merb_gems_version  
dependency "merb-slices", merb_gems_version  
dependency "merb-auth-core", merb_gems_version
dependency "merb-auth-more", merb_gems_version
dependency "merb-auth-slice-password", merb_gems_version
dependency "merb-param-protection", merb_gems_version
dependency "merb-exceptions", merb_gems_version
 
dependency "dm-core", dm_gems_version         
dependency "dm-aggregates", dm_gems_version   
dependency "dm-migrations", dm_gems_version   
dependency "dm-timestamps", dm_gems_version   
dependency "dm-types", dm_gems_version        
dependency "dm-validations", dm_gems_version  

dependency "merb_datamapper", merb_gems_version
dependency "do_sqlite3" # If using another database, replace this

On y liste ainsi tous les gems de merb et Datamapper que l'on souhaite utiliser. Si on veux en utiliser de nouveau, il suffit d'en ajouter à cette liste. Vous pouvez aussi en supprimer de cette liste pour diminuer ainsi le nombre de gem chargé dans votre application.

Utilisation d'un repository de gems local à votre application

Voici un point qui différe grandement de RubyOnRails. Mais à mon sens, là encore il est beaucoup mieux conçu que Rails. En effet, l'idée est très simple. Rubygems permet de définir le dossier où se trouve vos gems. Pourquoi ce répertoire ne serait pas simplement dans votre application ?

Pour mettre en place cette technique, il faut au préalable créer le dossier /gems/ dans votre arborescence. Ensuite utiliser les tâches thor pour installer les gems que vous désirez directement dans votre nouveau répository gems. Ainsi pour installer merb-core et datamapper, il vous suffit de faire :

$ thor merb:gem:install merb-core dm-core

Une fois fait de même pour toutes vos dépendances. Vous avez freezé votre application avec tous les gems utilisés.

Si vous utilisez un gestionnaire de source, il faudra alors n'ajouter à votre repository que le dossier /gems/cache/ en effet, ce dossier contient les .gem que vous utilisez. Les autre dossiers seront générés. Ensuite si quelqu'un récupére vos sources, il lui suffira de réaliser la commande thor de redéploiement :

$ thor merb:gem:redeploy

Tous les gems dans le dossier cache seront ainsi installé dans votre dossier gems. Là où je trouve que ce système est meilleur que celui de Rails est que si vous avez un gem avec un extension C vous pouvez le freezer avec Merb. Chose que vous ne pouvez pas faire avec Rails.

Mais et si je veux utiliser les versions de développement ?

Voici selon moi le point faible de Merb face à Rails. En effet, avec rails, rien de plus simple. On met les sources dans le dossier /vendor/ soit /gems/ soit /plugins/ et roulez jeunesse, tout fonctionne sans changement. Un simple git-submodule permet de suivre l'évolution du tout. Mais Merb ne permet pas ça. Merb ne loadera que des gems et uniquement des gems.

Technique recommendée par la core-team

La technique que finalement la core-team recommende est encore une fois de se baser sur les gems. Pour cela, rien de plus simple, il suffit de créer le gem correspondant à votre version de développement, l'ajouter dans le dossier gems/cache et ainsi l'utiliser. Des tâches utilitaires existent pour aider à tout ça. Par exemple pour installer la version de développement de Datamapper, vous pouvez faire :

$ thor merb:source:install dm-core

Cette tâche créera un clone du repository dm-core dans votre dossier /src/, générera le gem et installera dans votre dossier /gem/. Vous pouvez aussi faire de même en installant les sources directement dans le dossier /src/ et utiliser le nom de votre dossier. Ca lancera la tâche rake package et installera le gem généré.

Ce que je trouve dommage avec cette technique est l'impossibilité de savoir réellement quel est la version utilisée. En effet, gem utilise un numéro de version fixe et on n'a pas forcement l'information du commit qui a généré ce gem. J'aime bien pouvoir juste en clonant un projet savoir exactement la source exact du gem que j'utilise. Donc soit sa version, soit son numéro de commit.

Ma technique pour permettre de contourner le problème

La technique que j'ai ainsi trouvé fonctionne, mais n'est hélas pas complétement optiminum. Dans mon fichier config/init.rb, j'ai créé une petite méthode :

def load_from_source(src)
  $:.unshift File.join(Merb.root, "src/#{src}/lib")
  require "src/#{src}/init.rb"
end

Ensuite dans le callback before_app_loads, j'ai pu faire appel à ma méthode

Merb::BootLoader.before_app_loads do
  # This will get executed after dependencies have been loaded but before your app's classes have loaded.
  load_from_source('will_paginate')
end

Avec un clone du repository will_paginate dans mon dossier /src/ will_paginate est ainsi chargé automatiquement avant le load de l'application et après le load de toutes les dépendances.

Par contre cette technique à un gros défaut que je n'ai pas réussi à palier sauf en proposant un patch à Merb (ce que je ferais peut-être, même si Merb en tant que tel est mort :'(). En effet, on ne peux loader à partir des sources qu'après le load des dependancies. Si vous voulez loader au milieu des dépendances, vous ne pouvez pas. Il faudra obligatoirement passer par le système des gems.

Ce qu'il ne faut pas faire

Je vous rassure, je l'ai fait, ce qui me permet de vous dire de ne pas le faire. Ainsi, il ne faut pas ajouter le require directement dans le dependencies.rb. En effet, le chargement des dépendences ne se fait pas à ce moment là. Ce n'est qu'un chargement d'une liste gems à charger. Si vous faites votre require à ce moment vous pourrez ainsi vous retrouver avec des problèmes d'ordre de chargement.

English translation

l'upcase d'accent c'est possible avec ActiveSupport

Alors que sur IRC quelqu'un demande, comment faire un upcase sur des accents et conserver ces accents en majuscule, je lui répond que ce n'est pas possible car Ruby 1.8 ne supporte pas l'UTF8.

Je propose donc une solution peu élégante. Lister chaque éléments qui soient considéré comme non modifié par upcase et faire une liste de gsub comme ceci

irb(main):002:0> puts "aéèb".gsub("é", "É").gsub("è", "È").upcase
AÉÈB
=> nil

C'est alors que Farzy nous fournit un bout de code qui évite mon code peu pratique et surtout fonctionne avec tous les caractères unicode.

% irb
>> $KCODE = 'u'
=> "u"
>> "éè".upcase
=> "éè"
>> require 'activesupport'
=> true
>> "éè".chars.upcase.to_s
=> "ÉÈ"
>> RUBY_VERSION
=> "1.8.5"
>>

Il faut effectivement utiliser la librairie ActiveSupport qui fournit un support UTF8, mais cela fonctionne parfaitement. Merci à lui pour cet petite astuce.

Activer un compte Redmine par la console rails

Si par le plus grand malheur vous avez bloqué l'envoi de mail sur votre machine où redmine est installé. Vos utilisateurs ne peuvent plus recevoir d'email d'activation de compte. Redmine étant super pratique, vous ne pouvez pas activer le compte directement par l'interface web. Il faut donc passer par la console rails pour activer ce compte. Voici donc les commandes à réaliser pour activer le compte.

Dans cet exemple, nous allons supposer que je veux activer le compte du login 'ook'

Premièrement, il faut se connecter en console dans le mode production, où celui utilisé par votre instance web.

$ ./script/console production

Une fois dans la console, il faut chercher l'utilisateur, changé son état et ensuite supprimer le token d'activation. La suite de commande permet cela :

rails@shinydedi /var/rails/redmine/current $ ./script/console production
Loading production environment (Rails 2.0.2)
>> u = User.find_by_login 'ook'
=> #<User id: 7, login: "ook", hashed_password: "8a45629b374f3e667ea72494246b17a11309ffff", firstname: "Thomas", lastname: "XXX", mail: "thomas@xxx.com", mail_notification: false, admin: false, status: 2, last_login_on: nil, language: "fr", auth_source_id: nil, created_on: "2008-10-27 18:50:54", updated_on: "2008-10-27 18:50:54", type: nil>
>> u.status = User::STATUS_ACTIVE
=> 1
>> u.save
=> true
>> t = Token.find_by_action_and_user_id('register', u.id)
=> #<Token id: 16, user_id: 7, action: "register", value: "brVmdX8Sf0IecApDEWs0BmiD6ZN3DgsDoshpBZ2e", created_on: "2008-10-27 18:50:54">
>> t.destroy
=> #<Token id: 16, user_id: 7, action: "register", value: "brVmdX8Sf0IecApDEWs0BmiD6ZN3DgsDoshpBZ2e", created_on: "2008-10-27 18:50:54">

Ça y est votre utilisateur est activé. Il peux désormais se connecter comme si il avait réalisé l'activation par mail.

English Translation

Mise à jour des options d'attachment_fu dans un model

Attachment_fu est un magnifique plugin rails à utiliser pour tout formulaire qui doit faire un upload de fichier. Je l'utilise ainsi dans mon projet pictrails. Au niveau du README d'attachment_fu, il faut appeler la méthode ActiveRecord#has_attachment dans le model pour configurer l'utilisation de ce plugin. J'ai voulu mettre à jour cette propriété à la volé dans pictrails. J'ai donc commencé à rappeler la méthode ActiveRecord#has_attachment en lui passant les paramètres qui ont changés. J'ai d'abord pensé que ça m'étais à jour les options en conservant les anciennes. Mais après quelques tests, j'ai constaté que ce n'était pas le cas. Si on voulait mettre à jour les propriétés d'attachment_fu par cette méthode, il fallait rappeler toute les options.

C'est alors qu'après une rapide investigation directement dans le code d'attachment_fu, j'ai constaté la présence de la variable attachment_options. Cette variable n'est en fait qu'un Hash reprenant tous les paramètre du model. En le modifiant, on pouvait donc conserver les anciennes options et modifier celle que l'on souhaite. Pour exemple, le commit c47be9d8590ea911f0c1fbd14401fef83e0081e6, fait la modification d'option avec attachment_options au lieu de has_attachment