12:23 <guardian> ddfreyne: so you're splitting nanoc into nanoc-core, nanoc-cli etc?

13:08 <ddfreyne> guardian: Yeah

13:08 <ddfreyne> I need to write down the motivation for that in detail, I think

13:09 <ddfreyne> But there are basically two reasons:

13:09 <ddfreyne> 1. Remove plugins from nanoc into their own repos/gems, so that the build doesn't fail if these are broken, and this also allows other people to take over maintainainership more easily

13:10 <ddfreyne> 2. Make it easier to write custom frontends on top of nanoc-core. What about nanoc-web? :D

13:10 <darix> ddfreyne: this plugin question is tricky imho

13:10 <darix> if the plugin is basically something every user will install anyway

13:11 <darix> that breakage matters just as much as if it was in the core.

13:22 <ddfreyne> darix: Agreed, but I intend to include common plugins in `nanoc`, so `nanoc` would depend on `nanoc-core`, `nanoc-cli`, `nanoc-erb`, `nanoc-haml`, `nanoc-sass`, ...

13:23 <ddfreyne> darix: The goal is to let nanoc run on all Rubies, but it's impossible ot test that with all the plugins. JRuby and Rubinius have trouble with native extensions, for instance

13:23 <ddfreyne> (and Travis is difficult)