oink as a gem - Githubissues

technicalpickles commented 14 years ago

I've been talking with the guys over at Scout about supporting oink in their Ruby on Rails Monitoring plugin. One of the hurdles we encountered was the setup of oink could stand to be a lot easier.

The best plan I could come up with would be to setup oink and its hodel_3000_complaint_logger be packaged and released as gems.

It looks like there was Rake stuff in place for generating gemspecs, but I don't think it ever got properly released. I've done some work to get it ready to be released as a gem, and be managed by jeweler. You can see it in action at: http://github.com/noahd1/oink

I've also updated the documentation to be more straightforward about how to get up and running.

This also depends on hodel_3000_compliant_logger getting released as a gem: http://github.com/topfunky/hodel_3000_compliant_logger/issues/issue/2

itsderek23 commented 14 years ago

Definitely like this! It makes the install very simple, coupled with the Hodel 3000 dependency. Seems less "hacky" to get get going.

noahd1 commented 14 years ago

I've never particularly liked the Hodel 3000 dependency. It was a convenience at the time since that's what we were using. In fact, I was expecting lots of complaints from people saying "we don't use Hodel 3000!!" but for some reason that never happened.

Wouldn't it make more sense to have it log (in whatever format) to a separate log file that doesn't require a specific dependency? I realize this would involve a rewrite of the parsing ... but it might be worth it and might ease some of the setup pains. Having it install as a gem might be a good idea too. I think initially it was a gem because the rails hooks weren't part of the codebase. Up for exploring installing it as a gem though.

itsderek23 commented 14 years ago

Noah,

Thinking the separate log file option through a bit. I don't think I have a set opinion either way yet:

Rails 3 uses a slightly different log format, so the parser will need to be updated anyway.
A separate log may make debugging the cause of the memory leak more difficult - there may be log output inside the Rails log file that may provide hints to the cause (big SQL query, logged call to a leaking library, etc). It's nice seeing the Oink output inline with this.
For big log files, it'd be nice to have a minimized Oink log file. Parsing would be faster.
Not depending on a special log format would be nice.

Again, still undecided...

technicalpickles commented 14 years ago

So, I understand how things are is less than ideal, with the hodel3000 dependency. However, I still think it'd be beneficial to ship a gem version of oink as is. It basically makes oink easier to use now.

WIth that released, then we can figure out if there's a better way of logging this information, ie in a different file, without hodel, etc.

noahd1 commented 14 years ago

I'm down for making it a gem, or at least flexible enough to be either a gem or plugin. In your original post, you said you had done some preliminary work, but the link pointed back to my repo. Where can I find the work you were referring to?

You're right, early on there was some work to release it as a gem, but as the functionality moved towards controller instrumentation in addition to the pure log parsing, it never really got updated or properly released.

technicalpickles commented 14 years ago

Here it is: http://github.com/railsmachine/oink

technicalpickles commented 14 years ago

Also, I should mention hodel3000 would still need to be released as a gem. I could probably just push it as is, and ask for forgiveness about doing so, or... could vendor it somehow.

technicalpickles commented 13 years ago

Any thoughts on this? I just came across another app I'd like to add it to, and was hoping to avoid having to go through the plugin route again.

noahd1 commented 13 years ago

Sorry for my delay in responding. I think the best route you outlined is to vendor hodel3000 logger in the oink gem. The last change to hodel3000 logger was January 08, 2008 so I think it's a fairly safe thing to do for the short to medium term.

I can merge in code this week and any other updates I need to do let me know. What do you think?

technicalpickles commented 13 years ago

Sounds brilliant. I don't expect there'd be any other changes, except to remove the fictional gem as a dependency, and copy the vendored version in and require it.

I may need to get this running tomorrow actually, so I might be able to verify those steps.

noahd1 commented 13 years ago

I merged in your changes (minus the dependency) and published the gem as version 0.1.0. Just wanted to get something out there. I'll publish a 0.1.1 with Hodel3000 vendored. Let me know if that's work you think you'll get to. If not, I'll take a crack at it.

noahd1 commented 13 years ago

How did you make out with this?

Oink is now a gem but neither vendors nor depends on hodel3000Logger. I noticed that you went some of the way with gemifying Hodel. Do you want to release that, and then I'll update oink to depend on it? I think in retrospect that would be the cleanest. Let me know - I would love to close this one out.

technicalpickles commented 13 years ago

Hey Noah, sorry for sluggishness.

It looks like you had a release or two since, with hodel_3000_logger having been released, and it being a dependency now. I ran through the README on a new app, and everything is looking good.

I believe we can close this now, good sir :)

noahd1 commented 13 years ago

Awesome. No problem. Thanks for opening this.

noahd1 / oink

oink as a gem #2