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

181–190 of 223 posts

Re: Taskfile: A Modern Alternative to Makefile

#181

Post by BiteCode_dev »

retrac wrote: post #163
appplication wrote: post #157

Earlier quoted context omitted.

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

Python has no standard and the language implemented by the reference compiler is a moving target. (E.g. every script in Python 2 that used print without () broke in Python 3. There were other breaking changes. Some software still depends on installing Python 2.). The ecosystem in general is similarly dynamic. It's common to install a set of specific versioned packages and Python interpreter to get a package running.…

> every script in Python 2 that used print without () broke in Python 3. There were other breaking changes. Some software still depends on installing Python 2

People had 15 years to move from 2 to 3.

I had to port dodo files from 2 to 3, it's a 10 minutes job. Most of the time, running 2to3 on it does the job automatically.

After all, you only use the stlib for task runners, delegating a lot of work to bash, and they are quite short.

> It's not really a language where you can write something and be confident it'll still work in ten years

I still have Python 2.7 projects running fine, and reinstalled one serving half million users a few month ago.

But even without this, Python was created in 1991, and Python 3 was released in 2008, that's 17 years between first release and the first big migration. To compare, go is 14 years old. In total.

Plus your build file will have been edited so many times by the end 10 years anyway.

Make has a lot going for it, but this is a terrible argument.

Re: Taskfile: A Modern Alternative to Makefile

#182

Post by dagmx »

Towaway69 wrote: post #180
dagmx wrote: post #175

Earlier quoted context omitted.

This exactly. the level of work needed to add a dependency in C+Make vs Rust+Cargo is huge.

Don't forget, banks still use cobol... Should be replaced... If only someone could! Herein lies the issue for me: should existing projects switch because they are deemed to be gatekeeping when in fact either they are fine with their technology choices or they have not the resources or knowledge to change but they aren't gatekeeping. The external appearance is the same whichever reason might be the truth.

I don’t think anyone’s advocating for changing old projects just for the sake of accessibility, but if someone was able to contribute a change that increases accessibility while preserving functionality, then that’s fine.

It’s how a lot of major OSS projects have shifted to cmake from make or scons. Granted cmake isn’t a pinnacle of ease of use either but it’s much easier imho to reason about and integrate with various tooling like IDEs

Ideals don’t have to be binary.

Re: Taskfile: A Modern Alternative to Makefile

#183

Post by Novosell »

rakoo wrote: post #86
meling wrote: post #83

Earlier quoted context omitted.

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.

No doubt sent from a device with fully open-source hardware stack, right?

Re: Taskfile: A Modern Alternative to Makefile

#184

Post by dagmx »

Towaway69 wrote: post #178
dagmx wrote: post #173

Earlier quoted context omitted.

Are people just going to ignore that I have a clear delineation in my comment about the difference of learning and contributing to a project, and instead throw unrelated strawman arguments at me? Driving and programming are different, and learning to program and contributing code to important codebases is different. The stakes are different, the entire paradigms are different. The on ramp to learn to drive is easy re…

Point taken but why is learning yaml easier then learning make? It seems that if its about the amount that needs to be learnt then we'll get nowhere. Make is easy for certain folks, yaml for others. If a project has been using make for years, should they be forced to replace it since someone believes they are gatekeeping? What happens if said project rejects a pull request that replaces said makefile with task file r…

the point isn’t to replace existing use. To take your analogy of cars, we aren’t retrofitting cars with new tech.

But maybe it means that new projects use a more accessible build system. I’m not saying Task is the answer, I’m just saying Make is an issue for a lot of reasons like accessibility and portability to multiple toolchains and systems.

If you’re just coding for yourself, it’s not important. Nobody is saying you should change. But if you’re coding for an ecosystem, it’s always worth evaluating where changes can be made and then evaluating case by case if the pros outweigh the cons.

Re: Taskfile: A Modern Alternative to Makefile

#185

Post by maccard »

jen20 wrote: post #166
maccard wrote: post #130

Earlier quoted context omitted.

It's not about being explicit it's about using an abstraction that doesn't fit what you're abstracting. Make operates on the abstraction of targets are files. If you don't confirm to that abstraction, make is the wrong tool. To use the hammer analogy, just because you're good at hammering something, doesn't mean you should use it for a screw. Tools like docker and terraform don't use conventional files for state. Run…

To be pedantic: in the default mode, Terraform _does_ use a normal file for state, and for locks, and Make dependency tracking works fine with it.

That's a fair point. Funnily enough, I have the same complaints about terraform - the out of the box defaults (local state/lock files, and how backends work) are nonsense and incompatible with how the tool is actually used.

Re: Taskfile: A Modern Alternative to Makefile

#186

Post by stephenr »

raverbashing wrote: post #82
stephenr wrote: post #55

Earlier quoted context omitted.

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

You can choose to use XML without XSD. That's entirely up to you.

You cannot choose to use YAML without the string 'no' becoming boolean false.

Plenty of people complain about the complexity with XML, and there is a valid argument there. Using it as an argument in favour of YAML is kind of ridiculous.

Re: Taskfile: A Modern Alternative to Makefile

#187

Post by rakoo »

Novosell wrote: post #183
rakoo wrote: post #86

Earlier quoted context omitted.

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

No doubt sent from a device with fully open-source hardware stack, right?

Is it conceivable to you that steps are possible, and getting rid of dropbox is a step in a direction ? That perfect is the enemy of good ? That you can't wait to find a perfectly pure plan before starting moving ?

Re: Taskfile: A Modern Alternative to Makefile

#189

Post by Kamq »

jen20 wrote: post #165
cjfd wrote: post #76

Earlier quoted context omitted.

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

Ah yes - the user should serve the computer, not vice versa, clearly. /s, in case it's necessary.

It's more that doing the 80% solution lets us spend time developing other things. And then we can have a bunch of other really cool stuff as long as the users are willing to work with it.

Which seems like a pretty reasonable trade-off for something that's free.

Re: Taskfile: A Modern Alternative to Makefile

#190

Post by BiteCode_dev »

trallnag wrote: post #152
BiteCode_dev wrote: post #141

Earlier quoted context omitted.

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

I don't disagree with any of that.

I just prefer Python to make, it's easier for me and most colleagues I met to write and to debug. And making a custom Python function when I need more than bash inside the dodo file is great.

But for someone used to make, why not used it?

Post reply on HN