Live data from Hacker News

Taskfile: A Modern Alternative to Makefile

cloudnativeengineer.substack.com

81–90 of 223 posts

Re: Taskfile: A Modern Alternative to Makefile

#81
post #27

Earlier quoted context omitted.

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.

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…

> Most companies use Git in a centralized way anyways -- they don't need the distributed feature of the system.

Even if you have a single centralized remote, git being distributed lets you work offline, because you have a full copy of the repository, and you can commit locally.

> 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

Google exists and can help if someone doesn’t know but needs to do that.

> because most Git repositories I've seen in my life were, essentially, write-only, just a glorified rsync.

[citation needed]. If you have more than one person, how can a repository be write-only?

Re: Taskfile: A Modern Alternative to Makefile

#82

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)

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.

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

Re: Taskfile: A Modern Alternative to Makefile

#83
post #76

Earlier quoted context omitted.

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

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

Oh yeah, tell that to Dropbox.

Re: Taskfile: A Modern Alternative to Makefile

#84
post #57

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…

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.

[deleted]

Re: Taskfile: A Modern Alternative to Makefile

#85
post #70

Earlier quoted context omitted.

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

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

What is the "Norway problem"?

Re: Taskfile: A Modern Alternative to Makefile

#86
post #83
post #76

Earlier quoted context omitted.

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

Oh yeah, tell that to Dropbox.

Don't use dropbox. That's not even just a thing to say, reclaim your autonomy and stop using a proprietary tool.

Re: Taskfile: A Modern Alternative to Makefile

#87
post #70

Earlier quoted context omitted.

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

What is the "Norway problem"?

“The Norway Problem” YAML has: when you abbreviate Norway to its ISO 3166-1 ALPHA-2 form NO, YAML will return false when parsing list of countries f.e ‘[GB, IN, NO,…]’

Re: Taskfile: A Modern Alternative to Makefile

#88
post #32

Earlier quoted context omitted.

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.

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 invok…

Plan 9 has introduced mk, a successor to make:

https://plan9.io/sys/doc/mk.html

It's basically the same with some niceties and good defaults. One of them is the introduction of attributes, the most prominent being virtual: a target can be virtual meaning mk will never check the existence of a file and always run the recipe.

Re: Taskfile: A Modern Alternative to Makefile

#89
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.

Re: Taskfile: A Modern Alternative to Makefile

#90
post #9

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 d…

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?

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

?
Post reply on HN