Make template more flexible with tuneable attributes

[patcon]

As suggested in #2, perhaps we could make the template a little more flexible as the php and openssh cookbooks have done:

https://github.com/opscode-cookbooks/php/blob/master/templates/default/php.ini.erb#L1898-L1900
https://github.com/opscode-cookbooks/openssh/blob/master/templates/default/ssh_config.erb#L3-L11

The second link in particular is useful to look at as it shows how camelcase can be derived from underscored values.

Will submit a PR later

[patcon]

Learned something new:
http://stackoverflow.com/questions/9524457/converting-string-from-snake-case-to-camel-case-in-ruby

Go figure.

EDIT: oops. ruby of rails. no go.

[patcon]

cc: @anusch-athari

As in the openssh cookbook, there are some commented out lines in the original template that should go into commented out lines in the cookbook attributes file. Thoughts?

[anusch-athari]

Hi @patcon

I don't really think it makes a big difference which way of generating the config file we use.
So I don't care if you merge yours or not. But I don't have a solution for keeping the comments in the config while using your approach.

I would say the main problem here is, if wegrind chooses to change it's configuration file this might break the cookbook.
There's nothing we can do about this as long as webgrind has code in the configuration file.
I added an option to disable the configuration in case this breaks or someone just wants to skip it.

[patcon]

Yeah, even as I was writing it, it didn't seem right for a php config file. Might consider talking to webgrind folks and see if they'd consider switching to an ini format. That way, could have the config file, complete with comment, and just add something to the bottom of the template that would allow configs to be written -- since overwriting a previously declared ini directive isn't an issue, it would be cleaner.

[anusch-athari]

Yep my thoughts exactly.
Great that you wrote a ticket, I thought about it, but it seemed as if webgrind isn't being actively developed atm.

[patcon]

Yeah, it looked the same to me -- and the issue queue is piling up a bit. Tweeted a msg to the maintainer about bringing some others on the help, so I'll keep you posted if I hear back :)
https://twitter.com/patconnolly/status/275358972700160000

[anusch-athari]

Great, hope he answers.

But stuff like this is one of my biggest problems right now. I really don't know how to handle the fragmentation and dead projects on github.
Yesterday I tried installing jenkins and some plugins with chef. I wanted to use a premade cookbook.
So I had to choose between using
https://github.com/heavywater/chef-jenkins (the one listed under http://community.opscode.com/cookbooks/jenkins)
https://github.com/fnichol/chef-jenkins
both with issues piling up. Or I could use one of the 108 forks.
After a couple of hours I still couldn't find one that worked without me monkey patching it. I always ran into bugs. (e.g. https://github.com/fnichol/chef-jenkins/issues/9)
It's kind of what is described here http://code.ahren.org/bit/you-cannot-fork-a-child.

How do you handle this kind of stuff?
Best way is probably to always try and contact the package maintainer to somehow get the patches in.
But what if that doesn't work? I can't start maintaining all those packages I use.

[patcon]

Ah yeah, the jenkins cookbook is particularly confusing. I've spoken with the maintainer, and he's a little frustrated with the landscape as well. From his point of view, there are just so many different ways that people might want to deploy and manage jenkins, that it seems impossible to maintain a cookbook that suits everyone.

To explain though, fnichol was the original maintainer and owner of the community site namespace, and then AJ at heavywater took it over because he'd been working on it heavily while creating a project called pennyworth that got some attention.

But yeah, the jenkins cookbook has been a bit neglected lately, and he's aware of that. While it might not be the best approach for the jenkins cookbook, I usually try to kick off a thread summarizing all the diverse efforts, and @-mentioning all the maintainers into a single issue to hash out whether they'd be interested in focusing efforts. Kinda like this (even though it didn't work out in this case):
https://github.com/previousnext/capistrano-drupal/issues/5

[anusch-athari]

Thanks for the endorsement.

I will try your approach for the jenkins cookbook. Who knows.
Created an issue over there: heavywater/chef-jenkins#23

[patcon]

👍