Discussion:
Announcing oolong: a config-based glue for `component`
(too old to reply)
James Laver
2015-03-17 10:02:50 UTC
Permalink
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
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@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+***@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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andrew Oberstar
2015-03-17 23:04:33 UTC
Permalink
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
Post by 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
--
You received this message because you are subscribed to the Google Groups "Clojure" group.
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
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
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@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+***@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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
James Laver
2015-03-17 23:29:42 UTC
Permalink
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
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 ***@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+***@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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
James Henderson
2015-03-18 09:07:02 UTC
Permalink
Hi James,

This looks very similar to Phoenix
<https://github.com/james-henderson/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
Post by 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
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@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+***@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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
James Laver
2015-03-18 09:29:36 UTC
Permalink
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
Post by 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
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
--
You received this message because you are subscribed to the Google Groups "Clojure" group.
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
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.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@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+***@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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
James Henderson
2015-03-18 09:49:42 UTC
Permalink
Thanks - thoughts inline :)
Post by James Henderson
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!
Post by James Henderson
* 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.
Post by James Henderson
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.
Post by James Henderson
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.
Post by James Henderson
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.
Post by James Henderson
James
Post by 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!
Post by James Henderson
Cheers,
James
I've been using stuartsierra's handy component library for a while now,
but I wanted an easier way of connecting components together.
Post by James Henderson
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.
Post by James Henderson
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.
Post by James Henderson
James
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
<javascript:>
Post by James Henderson
Note that posts from new members are moderated - please be patient with
your first post.
Post by James Henderson
To unsubscribe from this group, send email to
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.
Post by James Henderson
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojure/T_skapDqZ0U/unsubscribe.
Post by James Henderson
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@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+***@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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
James Laver
2015-03-18 10:02:21 UTC
Permalink
Responses inline :)
Post by James Laver
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
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@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+***@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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...