OK, I've done a fair amount of work on Mars, and I think it's working decently now. Here's a basic run-down of the changes: * Packaged as a gem I've rearranged things into a more conventional bin/, lib/planet structure. I've also removed some of the tests on dependent libraries, assuming that they should take care of themselves; the way gems handles dependencies means it should be much easier to get your dependencies automatically installed. The biggest issue is the latest (required) version of html5lib is not available as a gem. Hosting our own copy of the correct version on github may make it easier, allowing us to to publish our own copy of html5lib 0.10.1 without making the maintainers cut another release. I've asked them about this, and they seem to be reluctant. The other issue is that rubygems doesn't currently have any notion of "We depend on this library OR this library." It might be possible to add this to rubygems, but (a) it's not a very common usage case and (b) it'll be a while before everyone would be using a new enough version of rubygems to make this useful. So I think this step will have to remain manual. Either that or just force usage of libxml. This may be better just because the expat bindings haven't been updated since the days of Ruby 1.6, and they are pretty buggy. * YAML configuration I know the INI config provides backwards-compatibility with Venus, but it's quite un-idiomatic and requires much more code to handle. I've rearranged this to be much simpler; see test/config.yml for an example. Having a separate section for subscriptions instead of just making them normal keys that happen to start with /http:\/\// makes things cleaner too. I've left around the INI-loading code, but I'm afraid I may have broken the sections that use it due to the separate subscriptions section mentioned above. If this were better tested I would have made an effort to keep both around, but since the repository didn't even have a sample .ini file to check it against, I left it in a bitrotten state. * ERB templates If any of the output templates ends in .erb, then it gets passed off to the ERB renderer. I'm not too happy with this right now since the splice code currently expects the templating engine just to accept a REXML document, and this results in extremely cumbersome code in the templates to extract values out of it. Two solutions come to mind: either we could wrap the REXML document in a more object-oriented class or switch to using rfeedparser internally. I've been using this library at work; it seems to be very robust, (not quite as much as the Python version--it has some encoding issues, but it's close) and the interface is much nicer. Also it's available as a gem. But this would probably involve a lot of changes internal to Mars, so I'm reluctant to jump in. It would also require using a template to render the output atom file since we couldn't just put a representation of the internal document. However, in my opinion this would definitely be the best way to move forward; I'd just like some feedback on what to watch out for. * Other stuff I've added a few test cases and a test helper. The test helper redefines a key Net::HTTP class so that it thinks that HTTP calls always result in 304... This means that since the HTTP cache is checked in to the repository, the tests will run without network access. This makes things easier to test in general, but that strategy may have to be adjusted once tests get written for the HTTP fetching functionality. I'd also like to include a good sample config with a template and images/CSS to make it look decent. The index.html.erb used in the tests is taken from planet.intertwingly.net; the sample template could be based on that. I've started something, but it needs work. Anyway, let me know what you think. It should be a lot easier for users to just pick up Mars and go now; fewer hoops to jump through and such.