Taskfile: A Modern Alternative to Makefile

https://cloudnativeengineer.substack.com/p/ep-5-taskfile-a-modern-alternative

by EntICOnc • 3 years ago

95 212 3 years ago

cloudnativeengineer.substack.com

arcanemachiner• 3 years ago

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

KRAKRISMOTT• 3 years ago

Taskfile looks heavily inspired by terraform and other "cloud native tooling (read: lots of yaml)

diimdeep• 3 years ago

horrible

stowaway1256• 3 years ago

Yep, `just` is much more truthful to the bare bones `make` legacy while `task` offers a bit more structured approach coming from inclusion of yaml as a specification language and many convenience things like handling env, run directories etc. I have worked with `just` for quite a bit but this looks very good honestly and I will consider switching.

SahAssar• 3 years ago

Terraforms native language is HCL, in most terraform setups I see very little yaml.

Maybe you're thinking of k8s and all of its related tooling?

haarts• 3 years ago

I, too, use just a lot in a very off handed way. My memory isn't great and I just toss commands in a projects justfile which I occasionally need. Yes, a readme would work to a degree too, but a justfile is runnable code. That beats dead documentation everytime.

armitron• 3 years ago

Whenever I read "modern alternative", it's nearly always certain that the older tech is superior on multiple fronts:

Better documented, better designed and architected (taking more use-cases / edge-cases into account), composable, easier to debug, fewer dependencies.

fncslothouber• 3 years ago

and usually also far less bloated

ginko2• 3 years ago

Just from reading the title i figured their idea of 'modern' was using something like yaml or json.

kristiandupont2• 3 years ago

How Yaml of all things became so popular is a mystery to me.

I am guessing the primary selling point is that it's sort of human readable similar to Markdown but even that (in fact, especially that) falls short when a configuration is more than just 5 lines, in my opinion. Trying to figure out which bullet this sub-bullet belongs to by holding my finger on the screen while scrolling is not an improved experience. And don't even get me started on the clever type system.

sangnoir• 3 years ago

Trying to figure out which bullet this sub-bullet belongs to by holding my finger on the screen while scrolling is not an improved experience

I don't see this as any worse than figuring out where nested parentheses are closed: tooling helps. I'm almost certain there's a whitespace plugin equivalent of Rainbow Parentheses for your IDE/editor of choice

taspeotis2• 3 years ago

Yelling At My Laptop

drewcoo• 3 years ago

How Yaml of all things became so popular is a mystery to me.

Well . . . the Perl folks, I think, came up with something less pointy than XML. And we all appreciated that because we'd all poked ourselves with XML too many times.

https://en.wikipedia.org/wiki/YAML

rewmie4• 3 years ago

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 crap about other tools without making any case for their own offering.

IceSentry2• 3 years ago

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.

trallnag7• 3 years ago

Taskfile is not an alternative to Makefile. It is first and foremost an alternative to PHONY targets in a Makefile.

Macha• 3 years ago

Which rounds to approximately all non C/C++ makefile usage

crabbone5• 3 years ago

I have coworkers who use this. They tried to make me use this too. I failed to see the point. It offers no benefits of a build system, no benefits of existing automation tools, comes with "bespoke" syntax and requires installing an extra program to run it.

I have never tested it enough to discover things it does wrong, but given how new and not exactly popular this tool is, I bet there are lots of things it doesn't do right...

So, I have no idea why would anyone want this tool... beside just using one extra infra tool to appear as if you know something others don't (and that's exactly the kind of people who use it at my workplace).

trabant00• 3 years ago

Because Make is too stable and well documented, because it's just one tool and not 3, because it isn't written in Go and because you don't have to scratch you head at another YAML hell. Because 47 years of proven track record is nothing compared to "modern". Need I go on?

thiht9• 3 years ago

If you think there’s nothing to fix with make, you’re severely mistaken. The differences between GNU Make and BSD Make are for me a big reason to be extra careful when using it. Make also relies a lot on cleverness so it comes with lots of idiosyncrasies (like having to add .PHONY to all the targets not representing files, which in itself proves Make was not thought to be used like we use it). Some basic conventions we use today are also hard to do correctly with a Makefile (using dotenv files for example)

I used Task on a new project and the explicitness of it all was a breath of fresh air. I mean which is clearer between:

    BINARY = ./foo
    GO_FILES = $(shell find . -type f -name '*.go')

    # Rebuild BINARY only if GO_FILES have been modified
    $(BINARY): $(GO_FILES)
     go build -o $@
    
    .PHONY: build
    build: $(BINARY)

and

    env:
        BINARY: ./foo
    tasks:
        build:
            cmds:
                - go build -o $BINARY
            sources:
                - **/*.go
            generates:
                - $BINARY

?

kmac_• 3 years ago

I remember how I promoted Git over a decade ago, and I heard from the lead guy that “SVN does the same” and “there are no benefits of using branches” (he never used them). Please listen to your coworkers and don’t be that guy. Technology moves forward, make it great, but it’s time to move on.

erik_seaberg3• 3 years ago

git's CLI is famously inconsistent, but git merge was obviously much more reliable than svnmerge.py ever had been.

(I hear svn may have improved merge tracking, but I'm not going to spend more time on it.)

crabbone5• 3 years ago

I didn't like the transition from SVN to Git. My biggest problem was the commit numbering. While SVN assigned consecutive numbers to commits, Git assigned hashes.

I still think that most people working with VCS today would've been better off using SVN. Most companies use Git in a centralized way anyways -- they don't need the distributed feature of the system. Most people using Git today don't know how to go back in history and wouldn't be physically able to carry out this task if requested because most Git repositories I've seen in my life were, essentially, write-only, just a glorified rsync.

I needed many years of working in infra to come to terms with Git and become efficient at using it. Most developers using it today will not have a multiple-year rotation in infra position, and are terrible at using the tool.

But this is very different from Taskfile vs Makefile. Git came with many attractive features. Some, perhaps inconvenient or demanding in terms of learning, but it was a genuine new tool that solved a problem other tools at the time didn't (branches were very expensive in SVN, sharding repositories across large distances was very expensive in SVN, and Git solved both).

Taskfile doesn't do anything better than any of the existing tools. It doesn't even promise anything like that... It's just "like make" but worse... so, what's the point exactly?

Technology moves forward

Oh you sweet summer child... no, it doesn't. Sometimes it moves backwards, sometimes it jumps in place pretending to do useful work... there's no rule to say it should, and the evidence abounds of how this statement isn't true.

inopinatus7• 3 years ago

sometimes there is great leap forward in build tools!

this is not one of those times

lloydatkinson• 3 years ago

This is a poor take. MAKE files have existed for decades.

waynesonfire• 3 years ago

I promoted Git over a decade ago

And from the response you got you failed at it. Were you promoting it because technology was "moving forward" and it was "time to move on"--whatever that means, instead of its merits? Didnt work for git, certainly won't work for Taskfile.

So, don't be what guy? The idiot that says branches have no benefits? The lesson is that there are dummies on both sides of the table.

Evaluate technology on merit. And, anything that is to dislodge a ubiquitous tool that's been around for 47 years has a high bar to cross.

JonChesterfield2• 3 years ago

This is the sort of logic that replaced make with cmake. New can definitely be worse than old. For example, cmake is terrible.

strokirk2• 3 years ago

Make doesn’t have any builtin —help for the list of user defined targets, and has a slightly wonky bespoke syntax of it’s own. So it’s quite natural to look for something that has those properties.

silverwind• 3 years ago

Targets can be conditionally defined, so a built-in help may be inaccurate.

crabbone5• 3 years ago

But Taskfile didn't improve anything about Make? Make has a huge user base, it's battle-tested in many environments, it has a ton of infrastructure around it...

Taskfile brings nothing to the table. It cannot compete with existing automation tools. It doesn't even promise to be better than existing automation tools...

I mean, give me at least some reason to believe it could be better than what I already have... to me it looks like the people who wrote it simply never saw what's already there. Kind of like a university project where students write a simplistic compiler for a subset of C language... It's nice that they tried their hand, but they have a long way before they actually produce something useful.

photonthug4• 3 years ago

This is the most real criticism of makefiles I've seen in this thread. There's fixes for it, but it usually involves parsing `--print-data-base` output, which is pretty awkward without reaching for a helper language like python/perl/ruby, and that then reduces portability and the batteries-included stuff that makefiles enjoy. It really does need a fix of some kind in make-core.

monocasa• 3 years ago

At least on debians using bash, tab completion will include the user defined targets.

datastack• 3 years ago

some tasks a developer might need to do besides just building the application:

- copying a database from production to local for bug reproduction/fixes - inserting seed-data into the local database - creating a migration after changing records - applying the migration - rolling back the migration - running a tool to copy configuration from a keyvault - running the end to end tests - generate certificates - set up an ssh tunnel to a remote server or database

All of these things are part of the development process, and cannot be part of the build system. Each of them has their own commands and tools.

All developers need to easily be able to do these things, without asking help each time, or learning the syntax of each command.

One easy way is to stuff all of them in a task runner with simple aliases. Another could be writing a document that you can copy/paste from. I prefer a task runner, since you can memorize the alias and work from the terminal without looking things up.

crabbone5• 3 years ago

So, what's your point exactly? There are plenty of tools for this that do it a lot better than Taskfile? Like, Ansible for example?

Also, what makes you think a build system doesn't or shouldn't do those things?

Also, you could just write a Shell script to do all of those -- what's the difference?

inopinatus7• 3 years ago

stuff all of them in a task runner with simple aliases

$ mkdir bin

easily be able to do these things, without asking help each time

$ ls bin

generate certificates

$ bin/mkcert.sh

What you didn't need: yet another tool and config syntax as a dumping bucket for your one-liners and command aliases.

Pesthuf• 3 years ago

I think I'd rather just keep using make .phony targets. The last thing I want is more yaml.

trallnag7• 3 years ago

There's also "Justfile" which is basically the same but with a syntax that is closer to a Makefile.

strokirk2• 3 years ago

I would take yaml and regular bash over long Makefile invocations every day.

choeger• 3 years ago

So what does make (the took is not called Makefile, btw) "wrong". Where could one improve on it?

1. Syntax. Makefiles aren't parseable and have some at least unexpected syntactic properties.

2. Dependency detection: AFAIK any make will always use a timestamp and the precision varies a lot. A checksum or at least guaranteed resolution would be great. Also, you can't depend on directories.

3. Dynamics (this is going to be contested): Changing dependencies and tasks at runtime is possible with GNU make, but not ideal.

Taskfile improves on problem 1 but probably worsens everything else.

feffe• 3 years ago

- Multiple out file dependencies are also difficult to describe in make (GNU Make). There's a dedicated section for how to solve it in the manual[^1] but it's a crutch.

- Taking environment variables into account as a dependency (they may affect Makefile logic and also code generation by tools that interpret them).

[^1]: https://www.gnu.org/software/automake/manual/html_node/Multi...

morelisp4• 3 years ago

Multiple outfile dependencies (aka "grouped targets") can be specified in GNU Make via `&:` since 4.3.

silisili• 3 years ago

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 haven't embraced the alternatives has to be pretty small...

amno7• 3 years ago

Why do you think they haven't evolved? Latest versions give you access to Guile scheme as an extension language, not to mention that they extended over time for quite a bit. But it is all backwards compatible so old makefiles still run.

morelisp4• 3 years ago

Make has no way to opt into lots of greybeard "best practices" by default, and the syntax is still difficult to deal with.

I want to keep the solver, which is pretty good. I want to keep the idea of targets, rules, recipes, which is what tools like Taskfile throw out that makes them not very attractive to me. I even want to keep a good chunk of the syntax for specifying these. But Make needs some kind of way to invoke it that switches off all the dumb shit.

- parse any reasonable whitespace indentation, for chrissake

- -r by default, or some way to opt into relevant sets of rules (e.g. `import "c"` to get CC, CFLAGS, %.o, etc.)

- Separate def syntax and namespacing for proper file-generating rules vs. phony rules, no more .PHONY or fake dependencies; also move stuff like .INTERMEDIATE or .PRECIOUS to the rule def.

- .DELETE_ON_ERROR, .ONESHELL by default, probably others I forgot

- better semantics for double-colon rules; once you know what the phony rules are you can make them operate in this mode by default and give better syntax for pre/post hooks, priorities, run-on-failure, etc.

- something solving the same problem as but less dumb than .SECONDEXPANSION (guile helps somewhat here but give me some help for the most common cases)

- stamp files implemented by some out-of-tree cache, they're just an optimization and I'd rather lose them now and then and have to rebuild, than have to keep adding them to every other tool's ignore lists.

As well as some actually new features to help manage targets without local inputs, e.g. smarter connectors for fetching dependencies from network resources.

chengiz• 3 years ago

The problem with Make is people abuse it with phony targets. If there's discipline in writing Makefiles and most targets are files, Make works quite well due to the basically simple timestamp/dependency stuff (vs say cmake which I honestly find harder to debug). There are obviously a lot of patchwork fixes and the absence of logical operators drives me nuts but overall I have yet to find a better, more battle tested tool.

raverbashing2• 3 years ago

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)

account-5• 3 years ago

If I had the choice of yaml and XML I'd probably choose XML.

mrweasel• 3 years ago

I can understand people not wanting to write Makefile and most of them just ends up being .phony and a bunch of shell code in many cases.

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.

trallnag7• 3 years ago

You don't have to choose one. M approach is to keep most "tasks" in separate script files and use Task (or just, or make, or doit, or...) to call and glue them together.

stephenr2• 3 years ago

XML is verbose. That’s the problem.

YAML is ridiculously complex, with a bunch of surprising behaviour.

I would take XML over YAML any day.

raverbashing2• 3 years ago

Basic XML is fine, maybe a bit verbose

But when you start getting into why are some things properties, or values, XSD or what not, then no.

Nobody has time for those thick XML books

BiteCode_dev16• 3 years ago

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 trying a lot of task runners and builders, I finally settled on doit:

https://www.bitecode.dev/p/doit-the-goodest-python-task-runn...

- It makes the simple things simple, and the hard things possible.

- It scales up (you get targets, dependencies, manual scripting, etc), but it also scales down (you can define a simple list of shell commands to run and that's it).

- Instead of a DSL, you have regular Python. Which for all it's faults, is an excellent scripting language. It has great tooling support, and comes with a debugger.

- To avoid people abusing the expressiveness of Python, the default syntax to create tasks encourages a declarative style.

I've been using doit for years, and every single project I introduced it to was improved by it.

Of course, it comes with it's own problems (non python dev can dislike having to install that, and it doesn't yet provide a stand alone executable), but the ROI is way better than the alternatives I tried.

emptysongglass2• 3 years ago

For Pythonistas or people interested in Python, I can't plug the commenter's newsletter enough: it is an absolute treasure trove of good advice for new and old users of Python. They did a whole series on the right way to install and use Python [1]. If you follow their advice you'll never struggle with any of the problems people complain of encountering with Python.

[1] https://www.bitecode.dev/p/installing-python-the-bare-minimu...

BiteCode_dev16• 3 years ago

Cheers :)

rewmie4• 3 years ago

DSL are the plague of our field, for one that is useful like SQL, you have a hundred that turn your life into hell.

The same can be said about using general purpose programming languages to specify stuff declaratively, but instead of implementation the problems happen in each and every single use of it. It only takes a single user that either does not comply with standards or feels they are particularly clever to mess everything for everyone.

BiteCode_dev16• 3 years ago

The dose makes the poison

sdflhasjd• 3 years ago

templated YAML based DSL are just insanity

The truest statement of all of HN

It started off with configuration files, but then we needed logic, control flow, or variables; and for some reason nobody goes "ok, maybe we need an actual progamming language now" and instead we've created horrors beyond our comprehension.

Azure Pipelines is the worst I've used: three types of variables, conditional statements return string "True" and "False", and of course it's mostly undebuggable.

BiteCode_dev16• 3 years ago

I have hopes that one day something like CUElang (https://cuelang.org) will become popular to be the configuration language of everything. Just enough logic to get by, but not turing complete, plus strong typing and embedded schemas.

However, for now there is just a single implementation in GO.

hitchstory2• 3 years ago

Templated YAML just means that something somebody thought was configuration either wasn't or wasnt under every circumstance. It's not really a problem with YAML.

In most cases I think it's the fault of the creators of the YAML DSL (e.g. ansible) but with CI pipelines people really just should be writing scripts 100% in other languages and wiring them up to events with YAML. I dont have any sympathy for people using them as programming languages.

I'm sure Microsoft is happy to indulge it though because hey, vendor lock-in.

veltas• 3 years ago

No need to apologise, I don't like YAML, I like Python, and I agree: I'd rather have a domain specific library than a DSL anyday.

The best of both worlds is a good programming language that allows expressing domain specific libraries almost as if they were domain specific languages, without going so declarative that people don't know how to script anything anymore.

I don't know if Python/doit really achieved that, but its task definitions seem almost as readable as the YAML, in a real language where I can do anything I want without asking permission. So I would always choose doit over Taskfile.

But a better comparison is between doit and make. I much prefer make's basic syntax, although I dislike newer features which inevitably have stretched the syntax beyond its original simplicity, but conceivably you can achieve something similar to make in a language but as a library rather than a DSL, and it would be immediately friendlier and more powerful than make. Depending on what I was doing I would use doit, but for something simple I've still got make (and it would be easy to convert if desired, in fact I have some projects in mind that could do with this!).

BiteCode_dev16• 3 years ago

Yes. I said it in another comment as well, but I'm rooting for a solid non turing complete conf language like CUElang (https://cuelang.org) to become popular. For now we can already use it to check and generate regular JSON or YAML, which is a good compat story.

But imagine having this in CI instead of YAML files.

tjoff3• 3 years ago

Python is such a massive dependency though, people who code in python rarely realize how big of a barrier it is for people not in that ecosystem. Package management is insane and every project has its own way of dealing with it. Installing python by itself is a chore on many operating systems.

BiteCode_dev16• 3 years ago

Agreed.

I wish more projects would compile their Python tool into a stand alone executable so that the users wouldn't have to deal with the installation process.

I will at some point write about how to do that with Python, so that the knowledge will more broadly available and maybe the community will grow the habit of doing it.

Meanwhile, I don't have more to offer than the "Relieving your Python packaging pain" procedure: https://www.bitecode.dev/p/relieving-your-python-packaging-p...

It's not perfect, but it's an improvement for any people that don't do a lot of Python but has to.

slondr• 3 years ago

Ruby is much better on the package management front and may be better suited to this task overall.

mid-kid2• 3 years ago

You can't run linux without python these days, and it's not hard to stick to packages available in the repositories.

Brian_K_White9• 3 years ago

And it breaks over time. Absolutely terrible choice for makefile. It would be far better to just use bash, even though it would mean coding your own dependecy and update-detecting logic. I wouldn't write anything in python that I still wanted to work a month later or on even one other system.

mongol• 3 years ago

I am thinking there must be a doit kind of tool but using bash shell instead. Anyone aware of one?

BiteCode_dev16• 3 years ago

People that love bash usually are comfortable with make.

pacifika• 3 years ago

No guarantees, but I use https://github.com/svandragt/Taskfile

Unfortunately it’s named the same.

theshrike79• 3 years ago

This is the exact reason why I moved to magefiles[0] in my Go projects. I had a semi-working Makefile base I spent days honing years ago, but then I ran into a few walls (can't remember which).

Enter magefiles, I could use the same language in them as I could with my other code and stuff just worked.

[0] https://magefile.org

Brian_K_White9• 3 years ago

Rather than downvote, since it's valid to state an opinion, I'll instead just do the same: Ugh. No.

zelphirkalt• 3 years ago

I guess that could work for a Python project, where you already have Python installed. But still you would need to set up a venv or similar to keep your system Python clean. Then you cannot run the tasks without creating that venv or similar. How to create the venv and install all the correct dev dependencies into it? You can't use the task runner yet, because you still need to install that ... Maybe a Makefile?

BiteCode_dev16• 3 years ago

That's why I'm advocating for compiling tools stand alone in another comments.

Having to install doit first is indeed going to be a barrier of entry for a lot of people.

It's still worth it in my experience, but I get how it can deter users.

erik_seaberg3• 3 years ago

Seems less file-centric than gmake. You have to repeat filenames in task commands, and depend on tasks by name rather than depending on generated files.

endgame• 3 years ago

Taskfile is just a dialect of YAML format with a specific syntax

One of the few formats in common use that's actually worse than Makefile, plus you need to go and find another binary to run the thing.

amno7• 3 years ago

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 language (in latest versions).

Also to note, the opening argument, writing Readme files on how to build and use the software, has nothing to do with Makefiles at all. You could write a simple skeleton codegen that generates a Readme file skeleton or a template with those steps autogenerated in any language preferred, shell included, and run it as a Makefile target.

emptysongglass2• 3 years ago

devenv.sh uses Nix, not Guile.

amno7• 3 years ago

I thought Nix used as Guix Guile under the hoos, but looked up now, and they seem to use custom language, in which case is it even worse. I should have looked up that before the hand, my bad there, I appologize.

Op complained about that make requires a bunch of extra tools to get running, and suggests another bunch of extra tools, as well as of make DSL which is more or less shell on steroids, but suggests a mix of two different languages instead, and does not even seem to be aware he can use Guile Scheme to extend Make.

tjoff3• 3 years ago

That is not the argument though. The argument is: After being unhappy with Makefile for years now

As to why being unhappy is probably not because it haven't been proof tested. I get your sentiment but feel the remark is out of place. I thought the rationale for picking other tools was straightforward and motivated.

Though the simplicity of make has been lost and I'm not sure the overhead is worth it. I wouldn't want to be the one introducing taskenv, direnv and derenv to a project.

inopinatus7• 3 years ago

Software build has essential complexity. Dealing with peculiarities in config syntax is a mere drop in the vast lake of unhappiness wept from having to deal with build at all. It's the tools that are salient, so folks may perceive that it's the tools at fault and must be reworked, but it isn't really: complexity in build tools is an emergent property of the domain, and any sufficiently developed reinvention will asymptotically correspond to makefiles.

amno7• 3 years ago

That is not the argument though.

But it was; one of his arguments. Yes, he opens with the argument that he was unhappy with the Make for years, but he later clarifies why:

I am still stuck with a tool that (according to Wikipedia) has been written 47 years ago.

You probably haven't read his article to the end? Those were his words I copy-pasted from the blog. So one of the reasons he is unhappy is because Make is 47 years old. For some reason, it stopped to be good enough 20 years ago, according to his opinion.

I can give him that we can always have a better tool, but it is a tautology. Unfortunately, his offered alternative is not better IMO.

taspeotis2• 3 years ago

Can you use spaces in filenames with GNU make yet? Seems like a 47yo vestige when spaces in filenames weren’t really a thing…

colonwqbang2• 3 years ago

Do we know that taskfile does any better than make on this front? It isn't mentioned in the article. Sounds like taskfile is runs on raw "command line string interpolation" just like good old make.

rwmj2• 3 years ago

Does this suffer from all the common problems with yaml (like the "Norway problem", but many others)?

cjfd• 3 years ago

Or just don't use spaces in filenames. It just causes trouble for no benefit.

EuAndreh• 3 years ago

In GNU make? Actually, yes:

    $ cat Makefile
    a\ file: ; echo 123 > '$@'
    $ make
    echo 123 > 'a file'
    $ cat a\ file
    123

ModernMech4• 3 years ago

It’s proof tested yes. But it still falls over if you put in a space versus a tab, and the error message is cryptic and frustrating to beginners. Make is such a huge impediment to C adoption, long time users have no idea.

Even the fact makefiles have no extension is confusing to beginners. Everything about it screams outdated, idiosyncratic computing artifact and students pick up on that.

Towaway694• 3 years ago

Having hurdles to jump over is perhaps a good thing? After all Torvalds built git to have a hierarchy of trust in the development of Linux.

If someone can't understand how to use make perhaps they shouldn't be fiddling with C.

amno7• 3 years ago

But it still falls over if you put in a space versus a tab

It fails only in a certain part of the script where tab is part of the syntax. It is like saying Python language fails if I add a wrong number of spaces, or replace a space with a tab, since white spaces are part of the Python syntax.

Even the fact makefiles have no extension is confusing

How is that confusing, the entire filename (makefile) is "the extension" :-)

Put .mk at the end of the file name if that makes you happy and less "outdated" and "idiosyncratic". C/C++ does not require extension either, it is just a convention. Ever seen <vector>, <algorithm>, <iostream> etc?

gorgoiler• 3 years ago

The command line entry points for your tooling need to be in the same language environment as everything else.

If your module in app/constants.py defines PORT which app/server.py serves and app/client.py connects to, how do you drop that same constant into your Makefile or docker-compose.yaml?

For me, literally everything including my docker, docker-compose, caddy, nginx, and of course the application code and all auxiliary scripts are presented as Python modules to solve this exact problem.

robbywashere_• 3 years ago

I use autoenv and a `./scripts` directory.

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

trallnag7• 3 years ago

That's basically what I use Taskfile for. And ensuring that things are always executed starting in the root of the repository.

prabhu-yu• 3 years ago

Scons using Pure Python Lang. No more DSL. https://scons.org/

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)

ginko2• 3 years ago

I used to swear by scons but it really collapses under its own weight when projects become larger.

At my work we used it for a fairly large source tree and no-change incremental builds would take a good minute for scons to figure out there's nothing to do.

These days we use something based on google blueprint which generates ninja build files.

high_priest• 3 years ago

Here I found an opinionated, but still very descriptive comparison of build tools the authors of SCons have experienced. https://github.com/SCons/scons/wiki/FromMakeToScons

lf-non• 3 years ago

We use this to trigger local tasks (like build, codegen, db migrations etc.) in our monorepo. We moved to it because our npm scripts were getting messier in absense of task dependencies, lack of multiline support, comments in json etc. Being an easy to use cross platform binary that can be managed through asdf made adoption very easy.

We have few colleagues working on react-native who use windows, and it is easy to support them because it uses mvdan/sh for script execution.

Being able to organize tasks into multiple module specific taskfiles which can be merged (with auto-prefixing) into the top level taskfile is quite nice. The support for watch mode, timestamp checking, environment propagation with built in dotfile support are all nice features that we found very handy.

It would have been nicer if it used hcl but I can live with yaml. I am glad that it doesn't use a real programming language - it makes it easy to look at a task in isolation (we have hundreds) and figure out what it depends on and what it does.

It is easy to be dismissive of such tools when glancing at the homepage, but it is one of those tools that grow on you when you give it a chance. The author has also been addressing a lot of common pain points over the years for which we are thankful - it is nice to be able to trigger tasks from any subdir (similar to npm run ...) and the new editor integration is quite too.

I see people saying that you can do all that this tool does using a few simple scripts. But these scripts only start off as simple, once you need a watch mode, cross platform support, timestamp change detection, selective argument propagation, need to exec dependencies in right directories etc. they tend to get buggier and messier.

jbverschoor• 3 years ago

Naming isn’t consistent with what make does and why it’s called Makefile.

Makefile is for make, which “makes files”.

You don’t “task files”

*file in general is wrong. Of course it’s a file

tannhaeuser2• 3 years ago

There are weirder choices in the realm of build tools, such as CMakeLists.txt.

colonwqbang2• 3 years ago

The article doesn't sell the tool very well. The flaws of make are well known, let's see some example of how this new tool outshines make? To me it looks like something very similar to make but with a different (slightly verbose) syntax.

Sirikon• 3 years ago

Correction:

Taskfile: It’s PHONY Makefile in Yaml

rakoo5• 3 years ago

I wanted to see what was wrong with Makefile and how Taskfile solved the issue, but the post doesn't explain; it's more a tutorial on how to use Taskfile. If the author reads this, I think we'd love to know what's wrong with make.

Also, a lot of those look like artificial complexity over a shell script sourcing another one containing only variables export, and running the required scripts.

thiht9• 3 years ago

If you don't know what's wrong with make, just use make. But it probably means you probably don't USE make.

If your Makefiles look like this:

    build:
       go build -o dist/app

You might as well just use make, it's fine. It's less fine when you want to avoid rebuilding if sources didn't change, or if you want to use environment variables, maybe from a dotenv file, or if you want to do conditions (like adding a debug flag to a build command if a make variable is set), or if you need to use make incantations (hoping they'll work with both BSD Make and GNU Make), then a Taskfile might help solving some issues, including legibility.

rakoo5• 3 years ago

I don't use make, so I wanted to see what was wrong with it, and the author's argument is that it's old. Not very convincing.

Your description starts to be more interesting, and I feel like mk (the successor of make from the Plan 9 people: https://plan9.io/sys/doc/mk.html) might address those, but again, I don't have a need for it.

pablo1• 3 years ago

Taskfile is great! I used it to write a NixOS deployment tool [1] which I have been using ever since

[1] https://github.com/pinpox/lollypops

TeeWEE• 3 years ago

Make is ubiquitous, it’s simple. Everybody knows it. That’s the reason to use it.

Just add a makefile to your repo and anybody is able it get started. I would have no clue what todo with a project in the structure proposed.

Note: I just makefiles as an entry point to the underlying build tool such as gradle or npm or go build

thiht9• 3 years ago

One day after writing a complex Makefile and getting frustrated because 1) it was hard to read and reason about because of make weird syntax, 2) it didn't run on CI because it uses GNU Make instead of BSD Make on my MacBook, I thought of writing a "modern" alternative:

I wanted it easy to read, write, parse and use, so I'd use YAML. You guys all shit on YAML because it's extremely badly used by, say, Helm charts, but it's a good markup language in itself. StrictYAML is anyway.

So I started writing a toy Makefile in YAML with these requirements: I need to run a command, with variables, it needs to depend on another command, and shouldn't run if the "output" file is already present and newer than the "source" files. So something like this:

    env:
        APPNAME: app
    clean:
        run: rm -rf ./dist

    build:
        depends:
            - clean
        input:
            - **/*.go
        run:
            - go build -o dist/$APPNAME
        output:
            - dist/$APPNAME

At this point I realized I had written exactly the same things proposed by Taskfile (which I heard of but thought "meh it sucks, Makefiles are great).

So yeah, Taskfiles are just Makefiles with a sane syntax and better tooling (JSON schema, auto generated doc, real default target...). I have no idea why the comments are so hostile towards it, because clearly Makefiles are not perfect (it's even a pretty bad format)

inferiorhuman• 3 years ago

   it didn't run on CI because it uses GNU Make instead of BSD Make on my MacBook

What?

  $ /usr/bin/make --version
  GNU Make 3.81
  Copyright (C) 2006  Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.
  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
  PARTICULAR PURPOSE.

  This program built for i386-apple-darwin11.3.0

thiht9• 3 years ago

My memories must fail me, I thought it was a BSD make vs GNU make issue but probably not! Maybe a version issue between the bundled make binaries on each platform, I don't remember the details to be honest

hitchstory2• 3 years ago

I'm the creator of StrictYAML and honestly, I would love to see something like this built with it.

I hate make and I dont like the idea of using non-typesafe YAML to build this (which presumably this tool does, since it's done in golang).

I've been using a "standardized" bash script with a huge case statement as a justfile/this/makefile replacement but it's not ideal.

thiht9• 3 years ago

Thank you for StrictYAML! I wish it was the standard

FullGarden_S• 3 years ago

Looking good. But no thanks, I'm sticking to my awesome tup.

rgrmrts• 3 years ago

Rake[0] is still the best ‘make-like’ build tool/task runner I’ve used for general purpose stuff. The syntax is nice and it’s just Ruby which is a delight. I briefly used Mage (similar, but Go) and it was fine too.

[0] https://github.com/ruby/rake

JonChesterfield2• 3 years ago

Instead of a DSL backed by some external tool, it's possible to write build scripts in a normal programming language. You only really need to implement "spawn process and give it these arguments" and "this depends on that" to reproduce most of C++ build scripts.

I've gone with lua and libuv because the concurrency model is so trivial. Each process spawn goes in a coroutine, stderr and stdout go into lua strings, use yield when the process is still running. However that comes with pretty minimal linting or error detection on the input, so maybe use some other language if you want that.

Or rephrasing, instead of a DSL for describing a graph and transforms to apply to the nodes, you can use a library in your favourite language instead. You might like that more than debugging cmake.

nunez• 3 years ago

I use Makefiles and native Bash in 2023 because both come on just about any system that will build and package my software.

Also, I disagree with Make being a bad task runner. In fact, I find it quite versatile. The fact that it is not a DSL with a meta programming language or, in the case of Taskfile, a YAML document that gets convoluted quickly (see also: Ansible) is a feature IMO.

devduderino• 3 years ago

Taskfile is a wonderful little tool.

Used with an alias it can be a wonderful way to manage scripts.

I use mine as a sort of global bookmark for shell commands I can't be bothered to memorize all the params for.

Handling env files is also a huge help.

c-hendricks• 3 years ago

My task runner is bash. After 15 years I've yet to find a system it's not installed on.

Bonus: you write your shell commands in a file that's aware of what's correct/incorrect.

inopinatus7• 3 years ago

Heartening to realise that that my venerable and slightly moth-eaten ThinkGeek t-shirt (ca.2001) emblazoned with "Go away or I will replace you with a very small shell script" remains relevant today.

deviantintegral• 3 years ago

We’ve been using Task for our (Drupal) web projects for a few years now and are really pleased with it.

Why not Make? We actually used that on a few projects previously, but found it challenging to use with both our teams and with typical tools used in the PHP and JavaScript stack.

1. Most of our newer hires have never used Make before, or anything like it. It seems to have fallen out of many curriculums in favour of other build tools, presumably due to decreasing focus on C / C++ in fundamental computer science classes. The idea that a build tool is inherently files based is a completely foreign concept. 2. File-based dependency tracking being the exception, and not the rule, simply works better with the majority of the types of tasks we run. Those include building docker containers, pulling down CMS databases for local development, and running CLI tasks like database migrations. 3. For those tasks that can be tracked with files, Task supports both timestamps and hashes.

One big win of Task over other tools is that it ships it’s own built-in sh shell. If you have tasks that run on a host and not in a container, it significantly reduces your host dependencies. Being a typical single-binary go app makes deployments easy too.

I’ll also say the maintainers have been very responsive to our few bug reports and feature requests, and responsive to our contributions too.

The worst part is yes, it’s another YAML DSL to learn. And personally, I wish Make had gained more traction in the web and docker world. But given all of the above, the trade offs of switching to Task have been worth it for us.

Taskfile: A Modern Alternative to Makefile

Related Stories