Added README
Getty Ritter
9 years ago
| 1 | The `yaml-dir` package lets you read in directory structures as | |
| 2 | though they were YAML object. Three sets of functions are exposed: | |
| 3 | one to treat all files as though they contain more YAML data, one | |
| 4 | to treat all files as YAML strings, and one to choose between the | |
| 5 | previous two based on file extension. | |
| 6 | ||
| 7 | # Why YAML Directories? | |
| 8 | ||
| 9 | The functions here don't care whether they're called on a file or | |
| 10 | a directory. This means that there's a certain level of structure | |
| 11 | that's lost to the application writer: there's no way of telling | |
| 12 | whether a given YAML object corresponded a directory or not. This | |
| 13 | is very much by design: to begin with, a configuration file like | |
| 14 | ||
| 15 | ~~~~ | |
| 16 | $ cat config | |
| 17 | sites: | |
| 18 | home: | |
| 19 | url: www.example.com | |
| 20 | port: 7777 | |
| 21 | blog: | |
| 22 | url: blog.example.com | |
| 23 | port: 7778 | |
| 24 | wiki: | |
| 25 | url: wiki.example.com | |
| 26 | port: 7779 | |
| 27 | ~~~~ | |
| 28 | ||
| 29 | isn't so bad, but if it gets larger, it becomes unwieldy. This | |
| 30 | allows a user to transparently use a directory structure instead, | |
| 31 | and pretend that directory structure is itself a YAML object: | |
| 32 | ||
| 33 | ~~~~ | |
| 34 | $ ls config/sites | |
| 35 | blog | |
| 36 | home | |
| 37 | wiki | |
| 38 | $ for f in config/sites/*; do echo $f; cat $f; echo; done | |
| 39 | config/sites/blog | |
| 40 | url: blog.example.com | |
| 41 | port: 7778 | |
| 42 | ||
| 43 | config/sites/home | |
| 44 | url: www.example.com | |
| 45 | port: 7777 | |
| 46 | ||
| 47 | config/sites/wiki | |
| 48 | url: wiki.example.com | |
| 49 | port: 7779 | |
| 50 | ||
| 51 | ~~~~ | |
| 52 | ||
| 53 | Both of the above will parse to the exact same YAML representation | |
| 54 | when using the `decodeYamlPath` or `decodeYamlPathEither` functions. | |
| 55 | ||
| 56 | # Why The Three Variations | |
| 57 | ||
| 58 | Each one does a slightly different thing: | |
| 59 | ||
| 60 | - `decodeYamlPath` and `decodeYamlPathEither` are for exactly the above | |
| 61 | use-case: taking a typical YAML config and blowing it apart into | |
| 62 | directories. | |
| 63 | - `decodeTextPath` and `decodeTextPathEither` are better for certain | |
| 64 | kind of data structuring: they treat every file as though it just | |
| 65 | contained a YAML string. | |
| 66 | - `decodeExtnPath` and `decodeExtnPathEither` are a compromise between | |
| 67 | the two: they will understand a file as YAML if it has the extension | |
| 68 | `.yaml`, as JSON if it has the extension `.json`, and as text otherwise. | |
| 69 | ||
| 70 | # What If I Need To Emit A YAML Directory? | |
| 71 | ||
| 72 | Don't do that. YAML is a nice input format, what with all kinds of | |
| 73 | small conveniences for humans and special-cases to make common | |
| 74 | things easy, but it's a _terrible_ intermediate format. There are | |
| 75 | multiple stylistic variations allowed for an identical in-memory | |
| 76 | representation, and this library only adds more. | |
| 77 | ||
| 78 | If you have an application in which a machine needs to emit data, | |
| 79 | there are various other formats which are better suited to that | |
| 80 | purpose: if it needs to be human-readable, then | |
| 81 | [JSON](http://hackage.haskell.org/package/aeson) or | |
| 82 | [S-expressions](https://github.com/aisamanra/s-cargot) | |
| 83 | might be better, and if it doesn't, then a format | |
| 84 | like [netstrings](https://en.wikipedia.org/wiki/Netstring) or | |
| 85 | [bencode](http://hackage.haskell.org/package/AttoBencode) might be | |
| 86 | preferable. |