Change Gioco installation options

[joaomdmoura]

Suppose that you start setting up Gioco with --points and then you perceive that you will gonna need also --types. Today there is no easy way to migrate, first you will gonna have to completely uninstall Gioco, losing all your badges and data, and then set it up again now with the both optionals.

The best solution would be a method that deal with the existent data and files that was generated. Not only to add option but also to remove.

The uninstall order of Gioco, if configured with only --points optional, would be:

• Remove rake file gioco.rake
• Remove configuration file gioco.rb (config/initializers/gioco.rb)
• Remove db/gioco folder and all files inside it.
• Remove the similar line of the db/seeds.rb: require "#{Rails.root}/db/gioco/db.rb"
• Remove the following models: Badge, Level
• Remove migrations related with gioco! Including add_points_to_*(YOUR RESOURCE).rb
• Remove the following methods of your RESOURCE model: change_points and next_badge?
• Remove all relations involving badge, level in your RESOURCE model
• Access your database of all environments, drop the Level and Badge table
• Also drop the Points column of your RESOURCE table. if you do this using migrations don't forget of delete this migration before keep working.

[gccostabr]

Can we assume we always have --types? Assuming we have a default type, if the user don't want to setup others on the app they are working on. We can think about the same approach for --points, where all badges will have a set point of 0 points, if not otherwise specified. And if a badge has 0, only an admin will be able to provide this badge to a given user.
Regarding the seed.rb, what about using migrations instead? I believe this could allow seamless integration with Rails conventions.
Thoughts?

[joaomdmoura]

I agree that assume types and points as default would be a good change, and certainly would make it easier to setup. But the rakes would have to deal with all this more complex context of optional arguments in all methods.

Migrations are certainly used frequently, but it wouldn't be right use it to populate tables, according to Rails guides:

Migrations are a convenient way for you to alter your database in a structured and organized manner.
Some people use migrations to add data to the database. However, Rails has a 'seeds' feature that should be used for seeding a database with initial data. It's a really simple feature: just fill up db/seeds.rb with some Ruby code, and run rake db:seed:
This is generally a much cleaner way to set up the database of a blank application.

The problem is that the seed file is executed completely every time that rake db:seed is called, and this can mess up the application database with duplicated data.
Add validation of existence inside the files included in seed.rb may be a solution, but idk if it sounds better than use migrations. Thoughts?