Explain best practices for forking core gem and adding new features

[Lordnibbler]

It is currently unclear, after forking spree/spree, how to fire up a new application for testing/adding a new feature.

@radar suggested to

1. Create a new application
2. Add gem 'spree', :path => "<path to spree>" to Gemfile

Perhaps add this to the http://guides.spreecommerce.com/developer/contributing.html in a new section about bugfixes/adding new features.

[Senjai]

This is not a spree issue. I'd like to say this kind of thing is covered in the rails guides, but I might be wrong. Anytime you want to use a local gem this is how you specify it in rails, whether that be spree or anything.

You could also just keep your own fork on github and gem 'spree', github: 'lordnibbler/spree', brach: 'my-branch'

[Senjai]

Also feel free to submit a patch too!

[Lordnibbler]

@Senjai I understand this is not a Spree issue. I recently submitted my first PR to add a feature to Spree and found it unclear from the documentation what the best practice was to follow for adding/debugging features. hould I generate a dummy app, and test my feature against that? Start a new rails app from scratch? How do I pick my "development" gem? Etc.

My feeling is, that although this is more Railsy info, that adding it will somewhat lower the barrier to entry to start adding/fixing features in spree.

[Senjai]

Right, but in that case we should link to the appropriate rails guides instead of duplicating ourselves here.

[Lordnibbler]

@Senjai I'm all for that -- is there a guide you suggest we link to?

[peterberkenbosch]

I love the sandbox script. bundle exec rake sandbox will generate an app for you in the sandbox folder and you can play around with it.

[peterberkenbosch]

Also, just working and clear specs do help as well.