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.
edn-lines is part of a growing collection of quality Clojure libraries and tools released on the Lambda Island label. If you are using this project commercially then you are expected to pay it forward by becoming a backer on Open Collective, so that we may continue to enjoy a thriving Clojure ecosystem.
deps.edn
lambdaisland/edn-lines {:mvn/version "1.0.10"}
project.clj
[lambdaisland/edn-lines "1.0.10"]
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.
(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}))
To print/read custom types, use the extension mechanisms provided by Clojure itself:
clojure.core/print-method
multimethodclojure.core/*data-readers*
(or provide a
data_readers.clj(c)
on the classpath)Printing happens with pr
, reading happens with clojure.tools.reader.edn
, but
with the reader functions from clojure.core/*data-readers*
passed in.
When dealing with ednl
files in the shell bb
-IO is your friend
bb -IO '(filter #(< 1 (:foo %) 4) *input*)' < test.ednl
Everyone has a right to submit patches to edn-lines, and thus become a contributor.
Contributors MUST
*
**
Contributors SHOULD
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.
Copyright © 2020 Arne Brasseur and Contributors
Licensed under the term of the Mozilla Public License 2.0, see LICENSE.
Can you improve this documentation?Edit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close