31–40 of 223 posts
I don't understand this argument: "it's 47 years old" as a bad thing. If something has been around that long, does it not mean it is proof tested? The syntax of Taskfile looks more verbose to me than Makefile, which is basically a shell script in disguise. To note also is that you praise Devenv because of it being based on Guix (Guile scheme), while you ditch Makefile which also embeds Guile scheme as the extension l…
It's a shame, IMO, that make hasn't really evolved. I've been at a few places that insist on still using them. They mostly work fine, but having PHONY littered everywhere gets a bit annoying. I don't think a successor can exist. Makefiles seem like the last of a dying breed - not because make is bad, but because there are better ways to accomplish this already. The market for people who've outgrown Makefiles but have…
Ok cool, let's see what this is about > Taskfile is just a dialect of YAML format with a specific syntax I imagined that. Ok bye Just write a js or python script. Or even a shell script Makefile syntax is bad but frankly YAML was a bad idea. (slightly less than XML sure)
Taskfile might be great for many use cases, but yes, why not just write a shell script. Almost every time I use a CI system, I end up falling back to just having it run a shell script, rather than relying on many of the build in features, because they are almost always a bit contrived. The same can be said for Makefile replacements, they try to predict what people need, and in the end it ends up being a fancy way of running a script.
I think I'd rather just keep using make .phony targets. The last thing I want is more yaml.
So my .env file just “includes” (automatically via autoenv) what’s in my scripts directory along with setting any environment variables when I’m jumping around my shell. Therefore I can just write a function like “dbup” or “devstart” and have those locally aliased to whatever they summon in the current project
Earlier quoted context omitted.
I found it amusing how the main features advertised for Task were the programming language used to write it, how it's distributed as a single executable, and how it's easy to install. None of them are relevant, or made any case for using it instead of just using the thing described in an international standard that is shipped by default in UNIX and Unix-like OSes for decades. It's like their selling point is to talk…
UNIX might be standard but it doesn't make it cross platform. You might not like it but a lot of people develop on windows. Build tools that assume a unix environment is present aren't a solution.
I fail to understand what point you tried to make. There are already plenty of Make implementations for Windows. If you think that installing a third party tool like Task is ok, I don't see how doing the same with a Make implementation would exclude it as a valid alternative.
It has cache facility to speed up re-builds. scons --implicit-cache I heard people say, Scons is slow, but it need not be if we use cache facility.
Some people say Meson (https://mesonbuild.com/) would be its successor, but I use scons for building my C/Python files. (ex: Python to .mpy files, asciidoc to pdf, html etc)
How does this compare with `just`[0]? I've never written a Makefile but I'm a big fan of `just`. [0] https://github.com/casey/just
Taskfile looks heavily inspired by terraform and other "cloud native tooling (read: lots of yaml)
Maybe you're thinking of k8s and all of its related tooling?
Earlier quoted context omitted.
I found it amusing how the main features advertised for Task were the programming language used to write it, how it's distributed as a single executable, and how it's easy to install. None of them are relevant, or made any case for using it instead of just using the thing described in an international standard that is shipped by default in UNIX and Unix-like OSes for decades. It's like their selling point is to talk…
UNIX might be standard but it doesn't make it cross platform. You might not like it but a lot of people develop on windows. Build tools that assume a unix environment is present aren't a solution.
Just because Windows decided to do everything differently to Unix and you decided to use Windows doesn't mean everything else has to adapt to be "cross platform".
FWIW, GNU Make runs fine in Windows if you're allergic to WSL
Sorry for the plug, but I can't help myself everytime I read about task managers to notice you have to learn yet another DSL. DSL are the plague of our field, for one that is useful like SQL, you have a hundred that turn your life into hell. Make's DSL is already full of gotchas, but templated YAML based DSL are just insanity. They have so many footguns, and so little flexibility and ability to be debugged. After try…
[1] https://www.bitecode.dev/p/installing-python-the-bare-minimu...