Hacker News Reader

Comment by duped | Hacker News Reader

How does it compare to waf (1)?

I've never used waf, but from its documentation it would seem that waf is a build system, implementing a concept of a DAG governing build of a project. That implies that waf is rather complicated.

jeeves, on the other hand, does no such thing. It is a command runner: you write a function → it is converted into a shell command.

I believe jeeves is easier to get started with, partially due to its simplicity and partially because it follows Python standards. For instance, waf uses a peculiar syntax to define command parameters:

waf employs a peculiar method to configure command options:

    ctx.add_option('--foo', action='store', default=False, help='Silly test')

while jeeves relies upon function arguments and type hints (as it is based upon Typer):

    def do(foo: Annotated[Option(help='Silly test')]):
        …

While jeeves is easy to start with it also promises ability to scale: with modular packages for commands, subcommands, and installable/shareable plugins.

Make is a build system, not a command runner, so you should probably change your copy; Jeeves doesn’t do what make does

I wouldn't necessarily agree. I've seen may instances of Make particularly being used to run tedious commands — linting, testing, deployment, et cetera; for these things, jeeves can be a perfect replacement. A and B are usually called alternatives if they have an intersection in their feature sets; there are no perfect alternatives.

That make can be used to run commands that don't build anything is just an artifact of how targets work.

If something is marketed as a make alternative, most people would expect it to, at the very least, possess make's core feature, which is skipping targets that have already been built and whose inputs haven't changed. That's what makes something a build system and not just a command runner.

The fundamental feature of make is building a graph of dependencies and building only the files that need building.

I say this as somebody that built their own python replacement for make long ago - during the building of which I learned what make was actually for, and how to use make, and thus abandoned my own project.

[1]: https://github.com/llimllib/pub

Don't know anything about waf, but the `ctx.add_option` example you've posted looks like it takes very similar parameters to add_argument in argparse[0].

[0]: https://docs.python.org/3/library/argparse.html#quick-links-...

Thanks for the point. I've had to deal with argparse-based code (not finding it very enjoyable) but didn't recognize the resemblance.

thanks -- I was under the initial impression that you intended jeeves as a "pythonic make". make isn't a command runner at all. Indeed, it relies on sh for that. It determines the DAG required to bring components up to date wrt dependencies. For example, you may have a postscript file and a pdf. Edit the postscript and you want the pdf regenerated:

my.pdf: my.ps

<tab> command to convert my.pdf to my.ps

Make makes no attempt to generate scripts, or anything like that. In general, make uses file timestamps to determine that my.pdf is out of date with respect to my.ps Make does have default commands that it can use. For example, it knows that executable w can be generated from w.c If I have a directory that contains w.c I can:

make w

cc w.c -o w

Now, because w exists, and is newer than w.c doing make w again does nothing!

make w

make: 'w' is up to date

I don't think that is what jeeves is?

You are right, jeeves doesn't do that. Your example reminds me of how I first learnt to use Make; I built my LaTeX stuff from source when in university.

However, dealing with Python mostly in my time in the industry, I scarcely ever had the need to use these particular features of Make. I used it as a task runner, guilty of that, — and that's what I wanted to reimplement in Python.

Even writing in Rust, everything I have to do is `cargo build`, — there is no need to write Makefiles for building the project.

I will consider changing that wording to set proper expectations, but I still feel that for me "a Pythonic alternative to Make" perfectly conveys the use case I daily employ this thing for.

I would also echo other commenters to stop comparing to Make if you do not have any intention of supporting DAGs or targets, which is indeed the entire point of Make. The fact you can use it as a task runner is a side effect/special case.

Reply on news.ycombinator.com