Designing a package manager from the ground up
circleci.com
circleci.com
Am I the only one who finds YAML to be difficult to reason about? I find that if the config is that complex, JSON or XML to be much easier to deal with. I think of TOML as the best balance between ease of use and expressiveness.
These ORBs sound similar to docker images, I’m surprised they didn’t offer a comparison, like “why not docker?”, or did I miss it?
executors:
alpine:
docker:
- image: alpine:3.6
parameters:
webhook_url:
description: URL to Slack webhook
type: string
message:
description: Message to post to Slack
type: string
commands:
notify:
description: "Notify Slack"
executor: alpine
steps:
- run:
name: Notify Slack
command: |
curl -X POST -H 'Content-Type: application/json' --data "{ \
\"attachments\": [ \
{ \
\"fallback\": \"<<parameters.message>>\", \
\"text\": \"<<parameters.message>>\", \
\"mrkdwn\": true, \
\"color\": \"#1cbf43\", \
} \
] \
}" <<parameters.webhook_url>>
orbs:
slack_notify: sirn/slack@dev
workflow:
foo:
jobs:
- slack/notify:
webhook_url: "..."
message: "..."
If this is all Docker containers anyway, why aren't they just creating Docker images and referencing them? They're just shoving a Dockerfile into YAML, without the benefit of it actually being a Dockerfile.
I rather have my json, but preferably XML with schema validation, having the joy of auto-complete and proper documentation.
I recently migrated a javascript project to typescript. We had some yaml based localization file and I decided to turn it into a typescript file by translating the yaml into json and then turning that into a ts file that exports constants. Crucially, typescript can do type inference and multiline strings.
The benefits of this are that I can now autocomplete keys in the file elsewhere in my code and get their type inferred correctly.
Similarly, gradle now supports kotlin in addition to groovy as a language for specifying build files in. The gradle dsl is more or less a declarative DSL. Using a statically compiled language such as Kotlin means you gain type safety and better tool support (autocomplete, correctness checking). Relative to Groovy you don't actually lose anything in terms of expressiveness but you gain a lot.
Neither typescript nor Kotlin are particularly more verbose than JSON though the lack of supporting a colon to map keys to values in a dictionary remains an unfortunate language choice in Kotlin.
Probably typesafe configuration DSLs are going to be a thing in the future. Neither JSON nor Yaml really do this. And schemas just add a lot of cruft.
You kind of need schemas. Or you need better type systems. I want at least regexp validation, interval validation, etc. from my configuration files.
In any case, you don't get any of that with most json/yaml based configuration languages. I seem to rarely encounter anything that comes with a schema.
My point was that the current config file formats are not good enough - I agree with that - but if we want to switch away from them, we need even better formats. They need to be at least good as the previous generation (XML), which had schemas. JSON and YAML are a regression which became popular because of their simplicity.
We need the simplest config format that comes with a schema. They should either come with a separate schema system or with a type system that is powerful enough to implement what I said before: regexp validation, interval validation. Without making you write more than validate="[a-z]*", not writing a whole class or such.