Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added optional config setup #7

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Added optional config setup #7

wants to merge 6 commits into from

Conversation

notch8
Copy link

@notch8 notch8 commented Nov 15, 2010

First off, thanks for maintaining a great template. I've been really happy with it, though there are a few things I was starting to change every time. For a while I've been maintaining me own branch with capistrano instead of inploy, exceptional instead of hoptoad and no inherited resource. It occured to me at RubyConf that it would be a lot better to merge with options and push upstream instead of just maintaining my branch forever. This pull request accomplishes that. It allows for the creation of an optional ~/.rails3_template.yml file where different gems can be turned off. I defaulted the config to use your current setup as the default (so exceptional and capistrano default to off).

What do you think?

Best,
Rob Kaufman

@dcrec1
Copy link
Owner

dcrec1 commented Nov 16, 2010

Hi Rob, I think it's a great idea! Just a few questions, can't be have options like 'rspec' instead of 'no_rspec'? I think its more clear, what do you think?

About the Capistrano and Exceptional options, maybe we can declare extra dependencies in the same yml file and read them in the template, what do you think?

@notch8
Copy link
Author

notch8 commented Nov 16, 2010

I went with "no_" under the thought that it was more likely you'd want to include something (and thus not have to add a config entry for it). Switching it around is easy, but that would necessitate a larger quantity of config options for default operation. Let me know if you still think it would be better switched

The yml file goes in the users home directory (not in the repo). I guess we could create the default file with those keys in the event there is no ~/.rails3_template.yml file. Is that what you are suggesting?

@dcrec1
Copy link
Owner

dcrec1 commented Nov 16, 2010

About the second point, im suggesting maybe we can have something like this in the yml file:

extra:
gem:
capistrano: '>=1.2.3'
exceptional: '=0.5'
plugin:
lorem: 'git://...'

And then read this things in the template, so if somebody wants the template plus an specific gem, he has only to define it in the yml file. Thinking better about this, maybe we can read from and rb file and require it in the template, so people can specify all the new dependencies using the rails syntax:

gem 'name, 'version'
...

Hope this time it got clearer :P

@notch8
Copy link
Author

notch8 commented Nov 16, 2010

nope dude, that's less clear not more clear, sorry :p

The template itself needs to support version of whatever is being included at whatever versions, otherwise it stops really being useful at all. Having to update the yml file for each version means keeping the version info in two places, which I don't think makes sense.

I'm not 100% sure you're understanding the way the yml file vs the defaults currently works. Right now if you have a yml file in your home directory it reads that and turns off whatever you specify there. Because I didn't want to force you or other existing users to create the yml file before using the template I set capistrano and exceptional as off (since you should not have both exceptional and hoptoad at the same time and should not have both capistrano and inploy at the same time). That way if you use this update it changes nothing for you or existing users until they decide to create a yml file and turn something off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants