From 8697555125c57ae64a0c9b78514b4aac4fd523de Mon Sep 17 00:00:00 2001 From: Mitja Felicijan Date: Tue, 27 Jun 2023 14:50:20 +0200 Subject: Massive formatting and added figcaption --- ...nting-task-runner-that-i-actually-used-daily.md | 158 ++++++++++----------- 1 file changed, 74 insertions(+), 84 deletions(-) (limited to 'content/posts/2023-05-31-re-inventing-task-runner-that-i-actually-used-daily.md') 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 17fdaf6..1abfd1e 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 @@ -5,55 +5,49 @@ date: 2023-05-31T12:21:10+02:00 draft: false --- -Couple 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. - -My 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. +Couple 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. + +My 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. My basic requirements were following: - Syntax should be a tiny bit inspired by Rake and Rakefiles. - Should borrow the overall feel of a unit test experience. - Using something like Python would be a bit of an overkill. -- The program must be statically compiled, so it can run on same - architecture without libc, musl dependencies or things like that. -- 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. -- 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. -- It should be an abstraction over bash shell or the default - system shell. +- The program must be statically compiled, so it can run on same architecture + without libc, musl dependencies or things like that. +- 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. +- 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. +- It should be an abstraction over bash shell or the default system shell. - Each task essentially becomes its own shell instance. - Must work on Linux and macOS systems. -- 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). +- 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). - Should support passing arguments when you run it from a shell. -- 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. -- State between tasks is not shared, and this makes this “pure” - shell instances. -- Should be single-threaded for the start and later expanded - with `@spawn` command. +- 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. +- State between tasks is not shared, and this makes this “pure” shell instances. +- Should be single-threaded for the start and later expanded with `@spawn` + command. - Variables behave like macros and are preprocessed before evaluation. -- Should support something like `assure` that would check if - programs like C compiler or Python (whatever the project - requires) are installed on a machine. +- Should support something like `assure` that would check if programs like C + compiler or Python (whatever the project requires) are installed on a machine. Quite 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. +Makefiles or/and Bash scripts. But I would like to avoid repeating myself every +time I start working on something new. So I started with the following syntax. @@ -111,13 +105,12 @@ end end ``` -One 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. +One 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. ```bash # How you do this things in make. @@ -126,43 +119,40 @@ target: python script.py ``` -This 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. - -By 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. - -Because I don’t use any external dependencies this whole thing can be -statically compiled. So that also checked one of the boxes. - -It 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. - -To 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. - -Another 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. - -I 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. - -I 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. +This 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. + +By 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. + +Because I don’t use any external dependencies this whole thing can be statically +compiled. So that also checked one of the boxes. + +It 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. + +To 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. + +Another 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. + +I 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. + +I 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. -- cgit v1.2.3