Announcing oolong: a config-based glue for `component`

[James Laver]

I've been using stuartsierra's handy component library for a while now, but I wanted an easier way of connecting components together.

To that end, I wrote oolong. The main mode of operation is to take an edn configuration file and connect the specified systems and components.

https://github.com/jjl/oolong

https://clojars.org/oolong

Feedback welcome. I spent quite a while documenting it so hopefully it should be fairly clear to understand.

James

[Andrew Oberstar]

Just a quick look so far, but it looks pretty interesting. I'm working on a multi-module project and I'd like to have the flexibility to run those modules separately or together. Extracting the component structure out into a config file could be pretty helpful in that regard. Nice work!

Andrew Oberstar

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Laver]

If nothing else, the functions in oolong.util should be pretty handy for manipulating them. Or can serve as a guide for manipulate them programmatically.

I’m working on a bunch of complementary stuff to this at present, including a library for developing components on top of oolong that will ease the transition between config-world and real-world, along with a bunch of components written to interoperate nicely. I’ve found that oolong simplifies interop in one major regard: specifying everything as nested maps means functions to start components will always take one argument. I’ve seen a lot of libraries do this to solve this problem.

James

[James Henderson]

Hi James,

This looks very similar to Phoenix - a project I've been working on for the last few months. It's pretty likely you hadn't heard of it (and that's fine - it's not been hugely publicised!), but if you have, I was wondering whether there was anything about it that you felt was missing/a bad design decision? If so, would be great to get your feedback!

Cheers,

James

[James Laver]

Hi James,

‘component’ is a difficult term to google for, so I hadn’t come across your project :)

I think your module had slightly different design goals from mine. Mine were:
* everything in one config file (although i also provide support for separate data-config and system config)
* be minimal. i’ve got a bunch of things i’m building on top of oolong at present that will together provide a more “complete” experience

I see you note that phoenix is ‘batteries included’. That’s a great experience for new users, but i wasn’t trying to build that on this occasion :) The leiningen template and plugin are also nice additions, and reloaded workflow integration is very handy.

Reloaded workflow has been an experience for me. I haven’t yet managed to get it working in the face of compile errors. I find myself restarting the leiningen repl about as much as before. For this reason I chose to keep it separate and delay dealing with it for a few weeks. Have you managed to overcome these problems? I’m definitely interested in knowing how if so.

I’ve only really given phoenix a few minutes of my attention so far, but I like what I see and I’m liable to steal ideas for some of the things i’ll be building on top of oolong. Feel free to reply offlist if you have any further questions.

James

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---

> You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/T_skapDqZ0U/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[James Henderson]

Thanks - thoughts inline :)

On Wednesday, 18 March 2015 09:29:59 UTC, James Laver wrote:

Hi James,

‘component’ is a difficult term to google for, so I hadn’t come across your project :)

Same problem here when I started writing Phoenix - there could be many libraries trying to solve the same problem!

 

I think your module had slightly different design goals from mine. Mine were:
* everything in one config file (although i also provide support for separate data-config and system config)
* be minimal. i’ve got a bunch of things i’m building on top of oolong at present that will together provide a more “complete” experience

Fair enough! I went for giving people the option of either one config file or multiple (after all, you don't *have* to use :phoenix/includes!) mainly because I got a lot of requests in Nomad (Phoenix's predecessor) for separate apps within the same company to share common configuration.

 

I see you note that phoenix is ‘batteries included’. That’s a great experience for new users, but i wasn’t trying to build that on this occasion :) The leiningen template and plugin are also nice additions, and reloaded workflow integration is very handy.

Hmm - Phoenix is 'batteries included, but removable' (phrasing stolen from Docker) which is significantly different from 'batteries included'. I'm not a fan of 'batteries included' - it tends to mean libraries that are hard for users to customise at a later date, which (to me, and to you as well by the sounds of it) goes against Clojure ideals. Phoenix is deliberately written as a standalone runtime library, which composes with whatever other systems people dream up, and a separate, lightweight plugin (not so composable), which essentially just bootstraps the library and saves people the hassle of a separate 'system.clj', 'dev.clj' and 'user.clj', if they so wish.

 

Reloaded workflow has been an experience for me. I haven’t yet managed to get it working in the face of compile errors. I find myself restarting the leiningen repl about as much as before. For this reason I chose to keep it separate and delay dealing with it for a few weeks. Have you managed to overcome these problems? I’m definitely interested in knowing how if so.

Happy to help with these - do you want to post some specifics? As a starting point, I've found that including an 'emergency nREPL' - an nREPL that starts before the application (and doesn't depend on the application compiling) gets you a long way. If the application doesn't compile, the system doesn't start, but I think that's actually preferable than half a system.

 

I’ve only really given phoenix a few minutes of my attention so far, but I like what I see and I’m liable to steal ideas for some of the things i’ll be building on top of oolong. Feel free to reply offlist if you have any further questions.

Feel free to steal ideas from Phoenix - that's what open source is all about! More than happy to work together on this as well though - seems like we have both come to very similar conclusions about how we want to wire up Clojure components.

[James Laver]

Responses inline :)

> On 18 Mar 2015, at 09:49, James Henderson <ja...@jarohen.me.uk> wrote:
> > On Wednesday, 18 March 2015 09:29:59 UTC, James Laver wrote:
> > component’ is a difficult term to google for, so I hadn’t come across your project :)
>
> Same problem here when I started writing Phoenix - there could be many libraries trying to solve the same problem!

I think there’s a general danger of this when writing tools that solve generic problems. The problem of discoverability is something that I found a lot of when I was writing a lot of perl as well. If you weren’t attending events and keeping up to date with what’s going on, you didn’t get to hear about all the cool things people were doing. I find the clojure IRC channel helps a bit with this.

> Fair enough! I went for giving people the option of either one config file or multiple (after all, you don't *have* to use :phoenix/includes!) mainly because I got a lot of requests in Nomad (Phoenix's predecessor) for separate apps within the same company to share common configuration.

*nod* I haven’t dealt with this yet. This is something my forthcoming library ‘kombucha’ (that i’m supposed to be hacking on right now, ho hum…) will have to deal with as well. I’m currently trying to figure out the best way to deal with what leiningen calls profiles while keeping the configuration format sane and simple. I see you’ve got some support for that, so I’ll be having a look shortly.

> I see you note that phoenix is ‘batteries included’. That’s a great experience for new users, but i wasn’t trying to build that on this occasion :) The leiningen template and plugin are also nice additions, and reloaded workflow integration is very handy.
>
> Hmm - Phoenix is 'batteries included, but removable' (phrasing stolen from Docker) which is significantly different from 'batteries included'. I'm not a fan of 'batteries included' - it tends to mean libraries that are hard for users to customise at a later date, which (to me, and to you as well by the sounds of it) goes against Clojure ideals. Phoenix is deliberately written as a standalone runtime library, which composes with whatever other systems people dream up, and a separate, lightweight plugin (not so composable), which essentially just bootstraps the library and saves people the hassle of a separate 'system.clj', 'dev.clj' and 'user.clj', if they so wish.

Yes. Sorry, I didn’t mean it as a negative comment. I think batteries included is great for getting people going quickly and I appreciate you’ve gone to some efforts to make it removable. However, you focus on the reloaded workflow aspect considerably in the documentation so I was under the assumption that was the case you were aiming to support.

> Happy to help with these - do you want to post some specifics? As a starting point, I've found that including an 'emergency nREPL' - an nREPL that starts before the application (and doesn't depend on the application compiling) gets you a long way. If the application doesn't compile, the system doesn't start, but I think that's actually preferable than half a system.
>

> Feel free to steal ideas from Phoenix - that's what open source is all about! More than happy to work together on this as well though - seems like we have both come to very similar conclusions about how we want to wire up Clojure components.

I expect this could get lengthy so I’ll follow up offlist. More than happy to work together if our ideas coincide.

James