We didn't design the gem to handle "dev" data, the idea was really to handle "real" data, such as Product in our case. Though if you feel like there would be a use case for dev seeds, I would be happy to discuss that with you (either here/twitter/mail etc ...)

I currently just use regular Rails migrations for this. In fact, I've executed each of the examples you provided using database migrations. You mentioned not wanting to use the console or a one-off script, but why would I want to switch over to SeedMigrations from regular ActiveRecord migrations?

While I haven't personally used seed-fu, it seems to solve a different problem. There are two main problems we're trying to solve here:

- Having the seeds.rb file mirror the records you need from production. You wouldn't want to to register your User model, since you don't want all your production users. You would want to register a model like Product.

- Being able to easily migrate data on our production systems. Being able to easily migrate (and rollback if something goes wrong) is key to having predictable deploys (for us at least).

It's key to migrate seeds on a "clean" database. Any models you register will be exported from the database into the seeds file, so we usually rake db:reset before running rake seed:migrate on development systems. We actually built this gem almost a year into our current system, so our first bootstrap of this loaded all the records from our production database for the models we needed (products, shipping types, etc.), which gave us a clean seeds file to use on development and test systems.