lambdaisland/edn-lines

Extensible Data Notation or EDN is a rich data format that is popular in the Clojure world.

This library contains helper functions for reading and writing files of newline-separated EDN values.

Support Lambda Island Open Source

If you find value in our work please consider becoming a backer on Open Collective

Installation

deps.edn

lambdaisland/edn-lines {:mvn/version "0.0-4"}

project.clj

[lambdaisland/edn-lines "0.0-4"]

Rationale

An edn-lines file (extension .ednl) is a file which contains one or more EDN collection forms, be it vectors, lists, or maps, with each form represented as a single line of text, and lines separated by newline ("\n") characters.

This way it is trivial to append to a file (for instance log messages or events), since there is no wrapping collection, and because one line = one form it plays nicely with traditional line-oriented tools like grep, head, tail, etc. If you grep an arbitrary EDN file you are unlikely to get valid EDN back, whereas you can grep an ednl file just fine.

Usage

(require '[lambdaisland.edn-lines :as ednl])

(ednl/spit "test.ednl" [{:foo 1} {:foo 2} {:foo 3}])

(ednl/slurp "test.ednl") ;; lazy seq of values

(ednl/with-append [append "test.ednl"]
  (append {:foo 4})
  (append {:foo 5}))

Use with Babashka

When dealing with ednl files in the shell bb -IO is your friend

bb -IO '(filter #(< 1 (:foo %) 4) *input*)' < test.ednl

Contributing

Everyone has a right to submit patches to this projects, and thus become a contributor.

Contributors MUST

• adhere to the LambdaIsland Clojure Style Guide
• write patches that solve a problem. Start by stating the problem, then supply a minimal, accurate solution. *
• agree to license their contributions as MPLv2.
• not break the contract with downstream consumers. **
• not break the tests.

Contributors SHOULD

• update the CHANGELOG and README.
• add tests for new functionality.

If you submit a pull request that adheres to these rules, then it will almost certainly be merged immediately. However some things may require more consideration. If you add new dependencies, or significantly increase the API surface, then we need to decide if these changes are in line with the project's goals. In this case you can start by writing a pitch, and collecting feedback on it.

* This goes for features too, a feature needs to solve a problem. State the problem it solves, then supply a minimal solution.

** As long as this project has not seen a public release (i.e. is not on Clojars) we may still consider making breaking changes, if there is consensus that the changes are justified.

License

Copyright © 2020 Arne Brasseur and Contributors

Licensed under the term of the Mozilla Public License 2.0, see LICENSE.