Hi Geoff
Thank you for using it and sharing your thoughts!
I'll admit that using eval and embedding clojure in the config file feels
> like a slippery slope. I'm worried I'll quickly make understanding clojure
> a prerequisite for editing the config file.
>
I totally agree. I'd hesitated to add the eval macro. But I follow the
principle of "Separation of mechanism and policy" as much as possible
in the development of baum, so baum doesn't care about how users
organize their configuration files.
Nevertheless, I think baum should have enough expressiveness to avoid
using the eval macro. If you notice lack of function you need (at
least, loop?), please feel free to post issues/PRs.
First, I wanted relative include paths to be resolved relative to the path
> of the file being parsed. I hacked around this in a messy way, but do you
> think it would make sense to either add a :relative-to-path or a
> :file-resolve-fn to opts to customize how relative paths are resolved? The
> :file-resolve-fn value would be a function called with the opts and the
> included file's path and returns the absolute path or any object slurp
> accepts. I haven't thought through how nested relative includes would work.
>
It sounds great. I think support for relative-path is common needs, so
I want to enable it without annoying configuration if possible.
I'll probably add new resolving strategy that handles a path starting
with ./ or ../ as a relative path to the current file.
Second, I wanted to customize how the contents of the included map was
> merged. For example, when both maps contained a key whose values are
> vectors I wanted to concatenate the vectors. I implemented this as my own
> reducer, but the other way would be to add a key to opts for controlling
> the merge behaviour of include/import/override. I don't know if this is a
> common enough requirement to warrant that though.
>
It also sounds great. I haven't decided yet how to achieve this, but I
think it is also a reasonable option to borrow leiningen's approach.
https://github.com/technomancy/leiningen/blob/master/doc/PROFILES.md#merging
Anyway, I’ve created issues besed on your suggestions on GitHub:
https://github.com/rkworks/baum/issues/1
https://github.com/rkworks/baum/issues/2
I intend to work on these problems in the near future.
Thanks!
Ryo
2015年4月11日土曜日 9時11分14秒 UTC+9 Geoff Salmon:
>
> Hi Ryo
>
> Thanks for releasing this. I've started using it for a configuration file
> that was previously an edn file. I was mainly interested in the import and
> include features but have now started using the eval macro to replace some
> repetitive parts of the file with for loops. I'll admit that using eval and
> embedding clojure in the config file feels like a slippery slope. I'm
> worried I'll quickly make understanding clojure a prerequisite for editing
> the config file. I'm not sure if the answer is to add a few more macros for
> common things like looping, or if I just need to be diligent and use eval
> sparingly or not at all. It seems easy to remove features in baum to
> enforce keeping the file simple, but I haven't taken that step yet.
>
> The import/include feature alone is useful though. I did hit two problems
> with my use-case though.
>
> First, I wanted relative include paths to be resolved relative to the path
> of the file being parsed. I hacked around this in a messy way, but do you
> think it would make sense to either add a :relative-to-path or a
> :file-resolve-fn to opts to customize how relative paths are resolved? The
> :file-resolve-fn value would be a function called with the opts and the
> included file's path and returns the absolute path or any object slurp
> accepts. I haven't thought through how nested relative includes would work.
>
> Second, I wanted to customize how the contents of the included map was
> merged. For example, when both maps contained a key whose values are
> vectors I wanted to concatenate the vectors. I implemented this as my own
> reducer, but the other way would be to add a key to opts for controlling
> the merge behaviour of include/import/override. I don't know if this is a
> common enough requirement to warrant that though.
>
> thanks again!
> Geoff
>
> On Saturday, 4 April 2015 05:59:27 UTC-4, Ryo Fukumuro wrote:
>>
>> Hi all,
>>
>> I'd like to announce the release of Baum.
>>
>> https://github.com/rkworks/baum
>>
>> Baum, my first public library for Clojure, is designed to create
>> "self-contained" configuration files.
>>
>> It allows you to include the following things in your configuration files:
>>
>> - References to external files
>> - References to environment variables with a fallback value
>> - Conditional loading of a part of config tree
>> - `let`
>> - etc
>>
>> And it is very easy to extend the DSL to add new features.
>> For more details, please see README.
>>
>> Any suggestions are welcome.
>>
>> Best,
>> Ryo
>>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
