Live data from Hacker News

Taskfile: A Modern Alternative to Makefile

cloudnativeengineer.substack.com

151–160 of 223 posts

Re: Taskfile: A Modern Alternative to Makefile

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

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

It's very rare, most distros ship Python, and even mac does it.

But:

- Half of the devs in the world are on Windows.

- Installing doit with pip is not trivial. Hence the "Relieving python packaging pain" procedure: https://www.bitecode.dev/p/relieving-your-python-packaging-p...

And most people will never ever encounter this article, so they will hit a missing command, a missing package, a PATH error, a PYHONPATH error, a version error or something like that. They may even try to solve it by copy/pasting many commands from the web, some of them with admin right, and make a mess of their setup.

That's why, for end user tools like doit, providing a stand alone executable is still the best solution.

Re: Taskfile: A Modern Alternative to Makefile

#152

Earlier quoted context omitted.

And yet you are here complaining about Taskfile and YAML overall. Nobody forces you to write full scripts in the YAML file. Just call scripts places somewhere next to it from it

Just because you have strats to minimize your exposure to something terrible doesn't mean the thing is less terrible.

But I'd do exactly the same with .phony targets in a Makefile. Keep the targets short and move larger chunks of code to individual script files that are just called from the Makefile

Re: Taskfile: A Modern Alternative to Makefile

#153
post #126
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.

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

Having try both, I would say quite the opposite.

Ruby package management is lacking in many ways. E.G: there is not good build in solution to manage projects and multiple versions of ruby on windows, it's all 3rd party. And C-extensions are still terrible to install

The apparent simplicity comes from the fact the ruby ecosystem is much smaller than the Python one, with 95% of it revolving around ror, so you are more often on the happy path and see less errors.

Re: Taskfile: A Modern Alternative to Makefile

#154

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…

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.

Re: Taskfile: A Modern Alternative to Makefile

#155
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…

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.

Thank you for StrictYAML! I wish it was the standard

Re: Taskfile: A Modern Alternative to Makefile

#156

Earlier quoted context omitted.

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

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.

Oh interesting.

I came up with basically the same thing as CUE (as described in [1]) on my own, except for the heavy schema stuff.

I think the schema stuff is unfortunately what's going to keep it from adoption.

I mean, I didn't add schema stuff explicitly in, but you can define schemas in mine, which makes it easier.

But making it explicit raises the bar for an implementation and may scare people away from writing one.

[1]: https://cuelang.org/docs/tutorials/tour/intro/json/

Re: Taskfile: A Modern Alternative to Makefile

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

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.

Could you elaborate on what you mean by it breaks over time?

Re: Taskfile: A Modern Alternative to Makefile

#158

Earlier quoted context omitted.

Explicit is better than implicit? If everything was implicitly PHONY then of course people would complain about that as well. This is a bit like typing in function-signatures. But what's the proposal here, acknowledgement that your use-case is the best / most normal for default behaviour? Should function sigs that are missing type-hints always default to strings because that works well with your project code?

Make is not a task runner. Let me quote from it's manpage: The purpose of the make utility is to determine automatically which pieces of a large program need to be recompiled, and issue the commands to recompile them.

And yet of course it runs tasks all the time in thousands of projects for decades, so there's the possibility that you're being overly literal and pedantic about the whole thing. Make specifies DAGs and helps resolve paths in them. A build is just a "program" where "recompile" is "re-execute task" and dealing with file-based dependencies is a special case.

Re: Taskfile: A Modern Alternative to Makefile

#159
post #148

Earlier quoted context omitted.

FWIW, both piloting and surgery have easy on ramps in guided settings, often with simulations. So even as a strawman analogies, they’re bad ones. Nevermind that you ignored the part where I delineated between learning and using it in important projects. I’m not even going to address the rest of your comment which is frankly a depressing outlook on life.

So, the 'easy on ramp guided path' to being allowed to pilot a plane or practice medecine, is as easy or even in the same universe with writing a makefile? Do you hear yourself? Talk about invalid arguments holy shit! The easy on ramp was it was totally free and permissionless to learn how to write a Makefile, or read a bunch of existing ones, or countless howtos, and that a basic makefile is basic and you don't need…

Is anger and derision your default state of discourse? Both your responses so far have been just completely over the top in both regards.

But putting that aside, you don’t think Make has a ton of footguns for someone starting out?

Spaces vs tabs for different bits because of decades of legacy? Oh but most editors default to tabs as spaces and suddenly no matter what you do, following tutorials will still fail.

Or you try and mess around with an existing open source project to learn from it. You want to list the targets? Oh wait, there’s no standard way to examine the makefile without understanding Make first.

If people consider Make easy to learn, imho they haven’t really reflected on how much more streamlined the rest of the software engineering ecosystem is, and how it benefits everyone from new programmers to experienced devs. I’m not the one saying it should be Python, I’m just saying Make is not a good solution in this day and age, when so many other ecosystems have shown they can have better on-boarding experiences.

Anyway I won’t respond further. Feel free to rage reply as you want.

Post reply on HN