Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taskfile: A Modern Alternative to Makefile

cloudnativeengineer.substack.com

Post reply on HN
Print view View original

101–110 of 223 posts

Re: Taskfile: A Modern Alternative to Makefile

#101

Post by tjoff »

BiteCode_dev wrote: post #63
tjoff wrote: post #57

Earlier quoted context omitted.

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.

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" proc…

Excellent, one of the problems with this is that you can't google it. Well, of course you can but you'll get a million contradicting resources and all that float to the top are too basic anyway. I really enjoyed your post, saved and will pass it along.

The mentioned "follow-up" article: https://www.bitecode.dev/p/back-to-basics-with-pip-and-venv (if you find the time, please add a link to it to make it even more complete)

Re: Taskfile: A Modern Alternative to Makefile

#102

Post by morelisp »

rakoo wrote: post #88
morelisp wrote: post #68

Earlier quoted context omitted.

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.

I've had the pleasure of using mk on a single project once and it was nice, fixing about 80% of what I think is broken in Make.

However it's an extremely hard sell to bring into a corporate tech stack today for either brown or green field projects.

Re: Taskfile: A Modern Alternative to Makefile

#103

Post by thiht »

inferiorhuman wrote: post #100
thiht wrote: post #99

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

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

Re: Taskfile: A Modern Alternative to Makefile

#104

Post by BiteCode_dev »

tjoff wrote: post #101
BiteCode_dev wrote: post #63

Earlier quoted context omitted.

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" proc…

Excellent, one of the problems with this is that you can't google it. Well, of course you can but you'll get a million contradicting resources and all that float to the top are too basic anyway. I really enjoyed your post, saved and will pass it along. The mentioned "follow-up" article: https://www.bitecode.dev/p/back-to-basics-with-pip-and-venv (if you find the time, please add a link to it to make it even more comp…

Thanks a lot, I planned to do it and I forgot. I've just added the link and it's indeed way better like this.

Substack doesn't really have any way to make a series of articles, or to bundle stuff together, so linking manually is the only thing you can do that will give a little structure.

One more reason to move off it when I find the time.

Re: Taskfile: A Modern Alternative to Makefile

#105

Post by thiht »

morelisp wrote: post #92
thiht wrote: post #90

Earlier quoted context omitted.

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…

What if you use `embed`? Why rebuild the binary if you've only touched test files? Make at least theoretically gives you tools to deal with these (but between Make and Go they're quite hard to use), but Task gives you no chance.

> What if you use `embed`

You can add the embedded files to the "sources" list, no issues

> Why rebuild the binary if you've only touched test files

Yep, this is a thing not currently supported by Task, but they're considering extended globing iirc (with negation, like in gitignores). I think you could do something like that though:

    env:
        SOURCES:
            sh:
                find . -name *.go | grep -v _test.go
kinda ugly, but easy to understand

Re: Taskfile: A Modern Alternative to Makefile

#106

Post by inopinatus »

kmac_ wrote: post #27
crabbone wrote: 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…

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.

sometimes there is great leap forward in build tools!

this is not one of those times

Re: Taskfile: A Modern Alternative to Makefile

#107

Post by lloydatkinson »

kmac_ wrote: post #27
crabbone wrote: 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…

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.

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

Re: Taskfile: A Modern Alternative to Makefile

#108

Post by inopinatus »

thiht wrote: post #90
trabant00 wrote: post #26

Earlier quoted context omitted.

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…

> which is clearer (..) ?

the makefile

Re: Taskfile: A Modern Alternative to Makefile

#109

Post by thiht »

inopinatus wrote: post #108
thiht wrote: post #90

Earlier quoted context omitted.

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…

> which is clearer (..) ? the makefile

In bad faith, yeah probably.

$@, .PHONY, and the implicit target/dependency syntax is clever, terse, but NOT clear.

Re: Taskfile: A Modern Alternative to Makefile

#110

Post by ModernMech »

amno wrote: post #21

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

Post reply on HN