[ANN] Introducing 'Phoenix' - a new library for declarative configuration and wiring of Component-based systems

[James Henderson]

Hi all,

I've just released Phoenix - a library for declarative configuration and wiring of Component-based systems. Phoenix came out of a number of discussions at ClojureX, thank you to all involved for their suggestions and feedback :)

https://github.com/james-henderson/phoenix

If you’ve written a traditional Component-based system, you’ve probably experienced having to create and maintain a plethora of ‘system.clj’, ‘dev.clj’, ‘user.clj’ etc type namespaces in order to wire-up the system, set up configuration-based switches, and duplicate the code to start/stop/reload the system. Phoenix removes the need for all of this, replacing it with one (or more, if you choose) EDN declaration of how your system should be wired up. It should also compose well with any other Components you (or anyone else) may have already written.

For a sample project, you can run 'lein new phoenix-webapp <your-project>', then 'cd <your-project>' and 'lein dev'. Once the nREPL is up, running '(phoenix/reload!)' will stop the system, reload any namespaces, and restart the system.

Phoenix is just one possible way of wiring up such a system - I understand that there are a fair few ideas floating around out there at the moment! I'd be really interested to hear your thoughts - whether it be 'this is mostly right, but I wouldn't do that part like that', or 'you've gone about this completely the wrong way, because ...' - let me know!

Cheers,

James

[Daniel Kersten]

Hi James,

This looks nice. I do have one question: is it possible to load parts of a configuration from environment variables?

Eg, in your "location-aware configuration" example, lets say I wanted to specify the database user and pass configuration options as you do for the dev configurations, but I want to load them from environment variables in the prod configuration?

Or, better yet, if it were pluggable (through tagged literals maybe?), so that I can choose where to load configuration from, eg, zookeeper or etcd). 

--
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.

[Leif]

Hi, James.

I'll let people with more experience with components critique your solution, but one thing that I thought was weird was that you had auto-namespaced keywords in the config file.  I'm referring to: https://github.com/james-henderson/phoenix#adding-dependencies-between-components

That means only code in your blessed ns can read the file, or things break.  Also, the edn spec disallows keywords beginning with "::".  So, I'd suggest either following the edn spec or using the ".clj" ending for the config files.

--Leif

[James Henderson]

Hi Dan - it's possible to load configuration from environment variables as of version 0.0.2 (released today) - you can now put [::env :env-var-name]in your configuration to look up the 'ENV_VAR_NAME' environment variable. More info in the env-vars section of the README.

Re: tagged literals: I'm pretty sure that's possible too - I can't see why it wouldn't honour readers that you put into your data-readers.edn file (haven't tried this out yet though), but there's currently no way to pass custom readers to Phoenix directly. I think this is one of the downsides of going for a plugin+library approach rather than just a library - I've split it out today so that it is possible to call the library directly, but it could still do with being a bit more flexible, I think!

James

[James Henderson]

Hi Leif - thanks for the suggestion. You're not the only person that's questioned the auto-namespaced keywords, btw!

The original reasoning behind them was to keep Phoenix-related configuration separate from the user's own configuration, but without enforcing typing :phoenix/ in front of all of the keywords. I'm not sure if this is the best/only way to do it, or even whether people would mind writing out :phoenix/component or :phoenix/dep every time they were required? Do you have any ideas/thoughts about how to do this? I'm happy to make breaking changes at the moment if necessary - Phoenix is still very much in 0.0.x territory!

Also, I didn't realise the EDN spec prohibited it, although now you mention it it makes sense that it should. I think, on balance, I'd prefer to resolve the problem rather than just accepting it and renaming the configuration file - if we can find the right way to solve it!

Thanks,

James