
Designing a package manager from the ground up - fro0116
https://circleci.com/blog/designing-a-package-manager-from-the-ground-up/
======
bluejekyll
> Orbs have a domain-specific language (DSL) defined in YAML syntax that
> expresses the semantics of our build configuration.

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?

~~~
jillesvangurp
At least yaml allows for comments. This is not supported with JSON (at least
not with most parsers).

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.

~~~
oblio
> 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.

~~~
jillesvangurp
That's the point of typescript. It has a type system. And regular expressions
are supported in javascript/typescript as well. Interval validation might be a
bit harder.

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.

~~~
oblio
I know that Typescript has a type system :)

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.

------
oblio
I really like their "volatile" decision. More package managers need to adopt
it, in my opinion.

------
iceninenines
Not another vendor-lock-in package manager. And, very predictably, no end-to-
end integrity and nonrepudiation. smh.

~~~
fwip
Which package manager do you feel gets it right?

~~~
jf
I’m not the OP but Nix/NixOS is the closest I’ve ever seen to a “Platonic
ideal” package manager

