[maybe] Convert make to python using pyinvoke

[atemate]

Possible alternative to #6.

In #6 (comment), @asvetlov proposed to use pyinvoke instead of Makefile. I've spent some time on researching this tool and here's the results:

The project seems to be alive with 2.5k stars and ~60 PRs, but many of them are very old (half a year, for example).

Pros:

• (by @asvetlov) is documented and well-supported, compared to a home-made solution
• (by @asvetlov) out-of-the-box supports command parameters and options
• (by @asvetlov) supports code completion out-of-the-box (sic! source <(invoke --print-completion-script=bash))
• no need to invent a wheel and manually implement runners and task collectors as we did Convert make to python #6

Cons:

• you have to pip install invoke before usage
• a bit more complicated code of tasks (targets): required argument context, required decorator @task
• no colored output! so looks like a mess. Of course, we can disable printing to stdin and stdout (or redirect them to log files), but IMO we should not mute anything in order to do this tool as much transparent as possible
• weird and non-switch-off-able warnings generated by the tool itself (Warnings during context.run(): ResourceWarning: unclosed file pyinvoke/invoke#665)
• no type annotations supported (Using python3 keyword-only arguments or annotated arguments causes a ValueError from inspect pyinvoke/invoke#357)

[asvetlov]

Cons:

• you have to pip install invoke before usage

In real life, you quickly start wanting to use additional libraries anyway. Even pip is not a part of stdlib. Simple bootstrap.sh can solve the problem.

• a bit more complicated code of tasks (targets): required argument context, required decorator @task

I consider this as a benefit, not an objection :)

• no colored output! so looks like a mess. Of course, we can disable printing to stdin and stdout (or redirect them to log files), but IMO we should not mute anything in order to do this tool as much transparent as possible

I cannot buy it.
invoke doesn't print anything itself. If you want to use ANSI sequences for output colorizing -- invoke doesn't strip them.

• weird and non-switch-off-able warnings generated by the tool itself (pyinvoke/invoke#665)

The warning is not shown by default. Would be nice to fix it eventually but it is not a show stopper.

• no type annotations supported (pyinvoke/invoke#357)

Not sure if annotations matter in tasks.py at all. Most likely people will ignore them here anyway.

[asvetlov]

What is the purpose of this setup.py file?
Do you want to publish it on pypi, import by python code, support versioning etc.?
From my perspective, tasks.py should live in the root of generated template code.

[atemate]

true, we can drop setup.py in both PRs (this and #6)

[asvetlov]

What is the purpose of the file?

[atemate]

local invoke configuration that. For example, setting echo: true prints the executed command in bold, which is very convenient. Since so far it's the only setting we actually use there, we can remove the setting file.

[atemate]

In real life, you quickly start wanting to use additional libraries anyway. Even pip is not a part of stdlib. Simple bootstrap.sh can solve the problem.

yes bootstrap.sh that does not use pip sound reasonable.

(no colored output) I cannot buy it. invoke doesn't print anything itself. If you want to use ANSI sequences for output colorizing -- invoke doesn't strip them.

still not working on my machine

The warning is not shown by default. Would be nice to fix it eventually but it is not a show stopper.

well, I don't know why but they are.

Not sure if annotations matter in tasks.py at all. Most likely people will ignore them here anyway.

agree.

[atemate]

Closing as for now we decided to stick with Makefile