Je place l'import A LA FIN, donc je dois le décaler à chaque fois. Donc changer le numéro pour le fichier, avec tout ce que ça génère comme complications et risques d'erreur. On zappe on oublie, puisque de toute manière ça ne me plaisait pas. Et puis si vous trouvez ça bizarre... faut voir le contexte générateur de bordel. Les spécifs sont DRY... au sens littéral du terme ;-)

C'est vrai que les migrations sont très bien pour charger des données dans certains cas. Je le fais et compte continuer à le faire pour certaines ! Mais dans mon cas certaines données sont à charger indépendamment. Qui plus est selon divers scénario depuis qq jours (démo pour machin, démo et tests par truc, celles pour la futur prod, ...).

Finalement j'ai ma réponse. Incroyablement simple et terriblement efficace : je fais des scripts au cas par cas et j'ajoute au début :

require 'config/environment.rb'

Et je pond mon code rails d'import. C'est aussi bête que ça, mais il me manquait cette satanée ligne pour coller les morceaux et me faire un script indépendant de l'appli, mais couplé au framework et au paramétrage.

J'aurais aussi pu utiliser "script/runner", mais coller ces traitements dans un modèle n'était certainement pas plus élégant dans ce cas de figure.

je ne comprenais pas trop ce que tu voulais faire.en fait ton serveur en production est pour l'instant un serveur de test.

a part ça quelques remarques,

1) j' etais surpris qu'ajouter dans ton script require config/environment.rb' fonctionne mais je suppose que tu as d'autres require dans ton script qui appelle ActiveRecord .cependant, il y a encore plus simple,tu peux faire ca en appelant en une seule ligne require config/boot.rb qui te charge rails et ton projet. c'est la methode qu'utilise le fichier rakefile de rails pour que les taches rake aient accés aux classes de rails et de l'application.

2)utiliser un script ruby externe n'est pas tres propre,les taches rake sont fait normal pour répondre à ce genre de probleme.tu peux rajouter des fichiers rake dans le repertoire repertoire_projet/lib/task.
exemple de fichier rake pour ton probleme

namespace :data do

desc 'initialisation des données'
task :initialiser do
#code pour charger les données
end
end

il suffit apres de taper rake data:initialiser sur le serveur en production pour charger tes données

3) si tu veux que tes migrations ne rajoutent pas de données à ton serveur en mode production,il suffit juste de rajouter ca à tes fichiers migration

unless RAILS_ENV == "production"
#code qui crée les donnés pour les tables
end


4)il y a aussi une solution avec capistrano mais j'ai pas l'impression que tu utilises capistrano.

Merci pour cette réponse.

Alors ...

1/===

Ca fonctionne. Comme bien souvent Google est un de nos amis, c'est ainsi que j'ai trouvé cette astuce. Devant une telle simplicité j'ai été sceptique, mais je te confirme que ça fonctionne. En tout cas pour l'instant ;-)

Maintenant je vais tout de même prendre en considération ta remarque et voir ce qui change avec le boot.rb

2/===

Merci pour le truc. Je n'ai pas encore pris le temps d'étudier Rake correctement, bien que j'avais déjà survolé la chose. Je note cela précieusement !

3/===

Ben... c'est plus compliqué. Ce n'est pas juste une histoire de serveur de prod, de dev,... j'en suis à monter des démos sur des machines virtuelles, avec des scénarios un poil différents qui n'aurons plus aucun intérêt dans 2-3 semaines.

4/===

Un peu comme rake, je n'ai pas encore pris le temps. Et même remarque que pour le point précédant, par rapport au côté temporairement bordélique...

J'ai reporté l'étude de Capistrano à plus tard. J'ai déjà mis en place Subversion récemment en espérant que l'intérêt de la chose soit compris ... mais un pas à la fois ;-)

En conclusion je reste à mes scripts puisque c'est temporaire pour certains, mais pour un truc propre je note l'option du rake.

Ce n'est pas toujours simple de se faire comprendre, surtout quand c'est déjà un peu le foutoir à la base. Mais merci de m'avoir répondu.