While I was building togomak, I read through Dagger [1], Earthly [2], Concourse CI [3], Jest and Make along with the stuff I was already working with - Jenkins, GitHub actions and GitLab CI. Dagger [1] is really great, I like its design - it supports writing pipelines in Python, Typescript, Go and a few more languages. togomak tries to abstract away a lot of it. Such as dependency management (in the case of python, the requirement of a python interpreter, and its package managers, etc). togomak is just a single statically-linked binary.
[1]: https://dagger.io/ [2]: https://earthly.dev/ [3]: https://concourse-ci.org/
> Such as dependency management (in the case of python, the requirement of a python interpreter, and its package managers, etc). togomak is just a single statically-linked binary.
Not sure if you've been following the latest updates about Dagger, but since the latest 0.9 release we have a preview feature where all the SDK tooling runs within Dagger itself as a container so they're not required to be installed in the host machine anymore. We've also added support for Dagger Modules which allows you to package and distribute pipelines a-la terraform. Our docs are still not updated yet but if you join our Discord server, you can find all the information there.
Cheers!
- Defining and validating data structures passed in; type doesn't have to be a basic type, it can be complex objects
- Default value
- Input validation criteria
So, with a real world example this is still going to be less verbose than the java equivalents.
You have a type defined, it's just string. There's no default, which means it's a required input. Required inputs obviously can't have a default. Arbitrary strings are a perfectly acceptable input and without seeing how that variable is actually used, I can't speculate about validation criteria and it is very reasonable that for arbitrary strings there are none.
variable "name" {}Other thing that is funny: no user-defined functions; being unable to use function calls in string interpolations, but allowing variables... so it is like saying: we have this parser and at some points it allows expressions, at some other point not. This seems wrong.
At the same time I agree with or at least understand original author's intent to squeeze HCL to maxinum. There is something appealing in HCL's visual form, at least when defining resources. Maybe it's just (almost) simplest form of defining such structures that can exists.
This is why I started to work on my own format for configuration, visually similar but with different model of computation.
Here is the first attempt: https://github.com/wkhere/bcl
Disclaimer: I named it BCL, 'B' stands for Basic, to somehow relate to HCL and make it easily pronounced. But later I discovered that another BCL is used as Google to configure the Borg platform and seems to be massively hated ;) So I look for a better name..
Project seems to be a bit stalled since few weeks, but that's illusory, as I have a rewrite with a non-yacc parser almost ready in the other branch. Then I will code parsing nested structures and at that point it will become really neat. Plus, an add of implementation in several other languages I usually code.
Please stay tuned if you like it.. or tell me what's wrong with it if you don't ;)
Beyond that, this just looks like yet another task executor... as you say, like make. At which point, you might as well just use a task executor. If make is not your liking, how about https://github.com/casey/just