Command-line cop-out plugin

[fatuhoku]

To increase adoption of pybuilder without supporting every possible thing Pythonistas would like to do under the sun, we'll want a python.exec_cmd plugin that lets users pretty much define their own arbitrary shell commands and incorporate them as a part of the build process.

Liken this to the Maven exec plugin

[mriehl]

Sounds like a good idea.
The main drawback is that the output will quickly clutter up the actual pybuilder output, while pybuilder tries to focus on the big picture.

I think that forwarding the output would only be appropriate when the command fails, or in verbose mode.

[mriehl]

I changed the requirements a bit because I think it fits the current plugin architecture better and it prevents you from doing too crazy things with it.

If you activate the plugin like so

use_plugin('exec')

Defining executions and when to run them is done with properties like

project.set_property('run_unit_tests_command', 'py.test %s' % project.expand_path('$dir_source_unittest_python'))

which would run py.test on the unittest directory during the run_unit_tests phase.
Replacing the property name with "analyze_command" would run this during the analyze phase instead, and so on.

You have fine-grained control over the output handling. The default is to write the stdout / stderr in a file in the reports directory.
If you want to have the output included in the pybuilder output, you'll have to use

project.set_property('run_unit_tests_propagate_stdout', True)
project.set_property('run_unit_tests_propagate_stderr', True)

Once again, you can replace run_unit_tests with another execution phase like package or publish.
If this sounds good to you, I'll build a new release.

[fatuhoku]

Yep, sounds good! Thanks @mriehl !

[fatuhoku]

So this hasn't been implemented yet has it?

[fatuhoku]

I'm confused as to the difference between an 'execution phase' and a 'task'. Surely they are the same thing, except 'execution phase' implies that there is some level of ordering of execution whereas task does not necessarily.

[mriehl]

The plugin is available since Version 0.9.11

Current version is 0.9.12

[mriehl]

Yes, exactly. I'm referring to the task name but for tasks where ordering is implied.
There are a discrete number of tasks than can be used with the exec plugin currently. I'm not yet sure how this can be generalized to work for arbitrary tasks but then again, I don't think that's necessary.

For very simple cases, defining a task in your build.py does the trick. The exec plugin allows you to skip the boilerplate code to run a shell command for the most useful tasks like testing, analyzing and packaging.

[fatuhoku]

Thank you, this seems to be working well.

I ran mamba, a Python test runner this way and found the log messages have lost their colours and have had all of its logging levels flattened to INFO. Do you think it's a good idea to let the exec plugin not only execute an arbitrary shell command, but let it execute an arbitrary Python function instead?

[mriehl]

In the case where a python function is available, I'd rather use something like

@task
def run_unit_tests(project, logger):
    my_mamba_entrypoint()

in your build.py. This would allow you to decide if you want to use the pybuilder logger or just let mamba write on stdout.

[fatuhoku]

Ah, very nice. Thanks!