aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--content/posts/2023-05-31-re-inventing-task-runner-that-i-actually-used-daily.md114
1 files changed, 85 insertions, 29 deletions
diff --git a/content/posts/2023-05-31-re-inventing-task-runner-that-i-actually-used-daily.md b/content/posts/2023-05-31-re-inventing-task-runner-that-i-actually-used-daily.md
index f2c19fa..17fdaf6 100644
--- a/content/posts/2023-05-31-re-inventing-task-runner-that-i-actually-used-daily.md
+++ b/content/posts/2023-05-31-re-inventing-task-runner-that-i-actually-used-daily.md
@@ -1,34 +1,59 @@
1--- 1---
2title: "Re Inventing Task Runner That I Actually Used Daily" 2title: "Re-Inventing Task Runner That I Actually Used Daily"
3url: re-inventing-task-runner-that-i-actually-used-daily.html 3url: re-inventing-task-runner-that-i-actually-used-daily.html
4date: 2023-05-31T12:21:10+02:00 4date: 2023-05-31T12:21:10+02:00
5draft: false 5draft: false
6--- 6---
7 7
8Couple of months ago I had this brilliant idea of re-inventing the wheel by making an alternative for make. And so I went. Boldly into the battle. And to my big surprise my attempt resulted in not a completely useless piece of software. 8Couple of months ago I had this brilliant idea of re-inventing the wheel
9by making an alternative for make. And so I went. Boldly into the
10battle. And to my big surprise my attempt resulted in not a completely
11useless piece of software.
9 12
10My initial requirements were quite simple but soon grow into something more ambitious. And looking back I should have stuck to the simple version. My laziness was on my side this time though. Because I haven’t implemented some of the features I now realise I really didn’t need them and they would bog the whole program and make it be something it was never meant to be. 13My initial requirements were quite simple but soon grow into something
14more ambitious. And looking back I should have stuck to the simple
15version. My laziness was on my side this time though. Because I haven’t
16implemented some of the features I now realise I really didn’t need them
17and they would bog the whole program and make it be something it was
18never meant to be.
11 19
12My basic requirements were following: 20My basic requirements were following:
13 21
14- Syntax should be a tiny bit inspired by Rake and Rakefiles. 22- Syntax should be a tiny bit inspired by Rake and Rakefiles.
15- Should borrow the overall feel of a unit test experience. 23- Should borrow the overall feel of a unit test experience.
16- Using something like Python would be a bit of an overkill. 24- Using something like Python would be a bit of an overkill.
17- The program must be statically compiled, so it can run on same architecture without libc, musl dependencies or things like that. 25- The program must be statically compiled, so it can run on same
18- Install ruby for rake is a bit overkill and can not be done with certain really lightweight distributions like Alpine Linux. This tool would be usable on such lightweight systems for remote debugging. 26 architecture without libc, musl dependencies or things like that.
19- I want to use it for more than just compiling things. I want to use it as an entry-point into a project, and I want this to help me indirectly document the project as well. 27- Install ruby for rake is a bit overkill and can not be done
20- It should be an abstraction over bash shell or the default system shell. 28 with certain really lightweight distributions like Alpine
29 Linux. This tool would be usable on such lightweight systems
30 for remote debugging.
31- I want to use it for more than just compiling things. I want to
32 use it as an entry-point into a project, and I want this to
33 help me indirectly document the project as well.
34- It should be an abstraction over bash shell or the default
35 system shell.
21 - Each task essentially becomes its own shell instance. 36 - Each task essentially becomes its own shell instance.
22- Must work on Linux and macOS systems. 37- Must work on Linux and macOS systems.
23- By default, running `erd` list all the available tasks (when I use make, I usually put a disclaimer that you should check Makefile to see all available target). 38- By default, running `erd` list all the available tasks (when
39 I use make, I usually put a disclaimer that you should check
40 Makefile to see all available target).
24- Should support passing arguments when you run it from a shell. 41- Should support passing arguments when you run it from a shell.
25- Normal variable as the same as environmental variables. There is no distinction. Every variable is also essentially an environment variable and can be used by other programs. 42- Normal variable as the same as environmental variables. There
26- State between tasks is not shared, and this makes this “pure” shell instances. 43 is no distinction. Every variable is also essentially an
27- Should be single-threaded for the start and later expanded with `@spawn` command. 44 environment variable and can be used by other programs.
45- State between tasks is not shared, and this makes this “pure”
46 shell instances.
47- Should be single-threaded for the start and later expanded
48 with `@spawn` command.
28- Variables behave like macros and are preprocessed before evaluation. 49- Variables behave like macros and are preprocessed before evaluation.
29- Should support something like `assure` that would check if programs like C compiler or Python (whatever the project requires) are installed on a machine. 50- Should support something like `assure` that would check if
51 programs like C compiler or Python (whatever the project
52 requires) are installed on a machine.
30 53
31Quite a reasonable list of requirements. I do this things already in my Makefiles or/and Bash scripts. But I would like to avoid repeating myself every time I start working on something new. 54Quite a reasonable list of requirements. I do this things already in my
55Makefiles or/and Bash scripts. But I would like to avoid repeating
56myself every time I start working on something new.
32 57
33So I started with the following syntax. 58So I started with the following syntax.
34 59
@@ -86,7 +111,13 @@ end
86end 111end
87``` 112```
88 113
89One thing that I really like about Errand. Yes, this is what it is called. And it is available at https://git.mitjafelicijan.com/errand.git/about/. Moving on. One thing that I really like is that a task is a persistent shell. By that I mean, that the whole task, even if it contains multiple command in one shell. In make each line in a target is that and you need to combine lines or add `\` at the end of the line. 114One thing that I really like about Errand. Yes, this is what it is
115called. And it is available at
116https://git.mitjafelicijan.com/errand.git/about/. Moving on. One thing
117that I really like is that a task is a persistent shell. By that I mean,
118that the whole task, even if it contains multiple command in one shell.
119In make each line in a target is that and you need to combine lines or
120add `\` at the end of the line.
90 121
91```bash 122```bash
92# How you do this things in make. 123# How you do this things in make.
@@ -95,18 +126,43 @@ target:
95 python script.py 126 python script.py
96``` 127```
97 128
98This solves this problem. Consider each task and what is being executed in that task a shell that will only close when all the tasks are completed. 129This solves this problem. Consider each task and what is being executed
99 130in that task a shell that will only close when all the tasks are
100By self-documenting I mean that if you are in a directory with `Errandfile` in, if you only type `erd` and press enter it should by default display all the possible targets. In make i was doing this by having a first target be something like `default` that echos the message “Check Makefile for all available target.” Because all of the tasks in Errand require a message I use that to display let’s call it table of contents. 131completed.
101 132
102Because I don’t use any external dependencies this whole thing can be statically compiled. So that also checked one of the boxes. 133By self-documenting I mean that if you are in a directory with
103 134`Errandfile` in, if you only type `erd` and press enter it should by
104It works on Linux and on a Mac so that’s also a bonus. I don’t believe this would work on Windows machines because of the way that I use shell instances. By you could use something like Windows Subsystem for Linux and run it in there. That is a valid option. 135default display all the possible targets. In make i was doing this by
105 136having a first target be something like `default` that echos the message
106To finish this essay off, how was it to use it in “real life”. I have to be honest. Some of the missing features still bother me. `@dotenv` directive is still missing and I need to implement this ASAP. 137“Check Makefile for all available target.” Because all of the tasks in
107 138Errand require a message I use that to display let’s call it table of
108Another thing that needs to happen is support for streaming output. Currently commands like `docker-compose` that runs in foreground mode is not compatible with Errand. So commands that stream output are an issue. I need to revisit how I initiate shell and how I read stdout and stderr. But that shouldn’t be a problem. 139contents.
109 140
110I have been very satisfied with this thing. I am pleasantly surprised by how useful it is. I really wanted to test this in the wild before I commit to it. I have more abandoned project than Google and it’s bringing a massive shame to my family at this point. So I wanted to be sure that this is even useful. And it actually is. Quite surprised at myself. 141Because I don’t use any external dependencies this whole thing can be
111 142statically compiled. So that also checked one of the boxes.
112I really need to package this now and write proper docs. And maybe rewrite tokeniser. Its atrocious right now. Site to behold! But that is an issue for another time. 143
144It works on Linux and on a Mac so that’s also a bonus. I don’t believe
145this would work on Windows machines because of the way that I use shell
146instances. By you could use something like Windows Subsystem for Linux
147and run it in there. That is a valid option.
148
149To finish this essay off, how was it to use it in “real life”. I have to
150be honest. Some of the missing features still bother me. `@dotenv`
151directive is still missing and I need to implement this ASAP.
152
153Another thing that needs to happen is support for streaming output.
154Currently commands like `docker-compose` that runs in foreground mode is
155not compatible with Errand. So commands that stream output are an issue.
156I need to revisit how I initiate shell and how I read stdout and stderr.
157But that shouldn’t be a problem.
158
159I have been very satisfied with this thing. I am pleasantly surprised by
160how useful it is. I really wanted to test this in the wild before I
161commit to it. I have more abandoned project than Google and it’s
162bringing a massive shame to my family at this point. So I wanted to be
163sure that this is even useful. And it actually is. Quite surprised at
164myself.
165
166I really need to package this now and write proper docs. And maybe
167rewrite tokeniser. Its atrocious right now. Site to behold! But that is
168an issue for another time.