Command line switch to display tasks

[adamralph]

trafficstars

[aarondandy]

This would allow tools like Scrawl for example to display a list of tasks that are available to be run from within the IDE.

[stirno]

:+1:

[adamralph]

Yeah, this really needs to get done. I need to make a general push on Bau features soon. It hasn't had enough love for a while :stuck_out_tongue:

[aarondandy]

Do you have any thoughts on how this would work?

scriptcs baufile.csx -- -list vs scriptcs baufile.csx -- task-name ?

What if I make a task named -list (not that I should)?

What about default tasks baked into Bau that can be overridden in a baufile to hide private tasks?

.Task("bau.list")
.MarkAsPrivateOrImplementationDetails()
.Do(() => {
    Console.WriteLine(ListOfPublicTasks());
    Environment.Exit(ExitCodes.ListSuccess);
});

Possibly related: https://github.com/scriptcs/scriptcs/issues/339

Makes me also wonder if a task should be marked as private or internal. I have a lot of tasks that simply make sure everything happens correctly or with proper ordering but I don't want people to invoke directly. Maybe another issue or you want to shoot that down here and now?

[adamralph]

My thoughts were to follow the precedents set by Rake and, to some extent, gulp:

scriptcs baufile.csx -- -T      # Display all tasks which have a description
scriptcs baufile.csx -- -A      # Display all tasks
scriptcs baufile.csx -- -P      # Display all tasks and their prerequisites

The idea of -T being that each task designed to be explicitly invokable should have some kind of description attached. Of course we would have to introduce the concept of task descriptions, e.g.

bau.MSBuild("build").Desc("Build solution").DependsOn(...).Do(...):

Bear in mind that the ultimate aim is for scriptcs to support command line packages, so there will eventually be a Bau.Cli NuGet package which installs bau as a global command, allowing:

bau -T
bau -A
bau -P

[aarondandy]

I like the description approach much better and it should be easy to implement. Want to include the .Desc(description) stuff in this issue as it is pretty much required? -T and -A are stupid simple but what does -P look like?

[adamralph]

Descriptions are already covered in https://github.com/bau-build/bau/issues/65 so this issue is probably dependent on that. I guess both could be solved in one PR though.

rake -P gives something like this (for https://github.com/xbehave/xbehave.net):

rake accept
    build
rake artifacts
rake artifacts/logs
rake artifacts/output
rake build
    clean
    restore
    artifacts/logs
rake clean
    artifacts/logs
rake component
    build
rake default
    component
    accept
    pack
rake pack
    build
    artifacts/output
rake restore

[aarondandy]

Currently Bau allows for whitespace in task names. The easy solution to this problem is to tell people "don't do that" but would it be better to wrap task names in quotes and do \ escaping if they contain whitespace or to restrict tasknames with whitespace? Escaping can be included in this task but restricting would need to be another item. Can this be ignored for now until somebody complains about it or would that be too reactionary?

[adamralph]

What is the problem with having whitespace in task names?

On 22:08, Tue, 21 Apr 2015 Aaron Dandy [email protected] wrote:

Currently Bau allows for whitespace in task names. The easy solution to this problem is to tell people "don't do that" but would it be better to wrap task names in quotes and do \ escaping if they contain whitespace or to restrict tasknames with whitespace? Escaping can be included in this task but restricting would need to be another item. Can this be ignored for now until somebody complains about it or would that be too reactionary?

— Reply to this email directly or view it on GitHub https://github.com/bau-build/bau/issues/166#issuecomment-94923051.

[aarondandy]

I wonder if it could cause issues for others when parsing the output. As I think about it though I guess it would be more of an issue if there were a # in the task name than whitespace. Even then a parser should look for \s# and not just # on it's own. It should probably be ignored for now.

[adamralph]

By parsing you mean automated parsing?

[aarondandy]

Yes.

[adamralph]

OK. So I think quote wrapping is probably the solution for that.

If we examine the current command line, Bau already supports the running of specific tasks like so:

> scriptcs baufile.csx -- build pack

In the case where a task has whitespace, the usual command line convention of quoting is used:

> scriptcs baufile.csx -- "build solution" pack

So I would expect the output to follow suit:

> scriptcs baufile.csx -- -T
"build solution"        # Builds the solution
pack                    # Creates the NuGet packages

I don't think # should cause any problems. If the output is as above, then the # which denotes the description is the first # which is prepended with whitespace outside a task name. A task name of the form a#b has no whitespace before the # and a task name of the form "a #b" is necessarily quoted so the parser knows the # is part of the name. It's true that this adds a little overhead to the parser implementation but we could also consider supporting some kind of serialized output specially for parsers. E.g.

> scriptcs baufile.csx -- -J
{
    tasks: [
        {
            name: "accept",
            description: "Run acceptance tests",
            dependencies: [
                "build"
            ]
        },
        {
            name: "build",
            description: "Build the solution",
            dependencies: [
                "clean",
                "restore"
            ]
        },
        ...
    ]
}

[stirno]

big :+1: to JSON output! Thats how we did it for pvc using a fairly ridiculous command line argument that i'm not happy with but life is much easier with JSON :)

[aarondandy]

My office will be moving on Friday and I think I will be kicked out of work. I want to see this implemented so I intend to take a shot at it :construction_worker: this weekend if I don't get sucked into Pillars of Eternity :feelsgood:.

[adamralph]

This has gone out in https://www.nuget.org/packages/Bau/0.1.0-beta09

[adamralph]

This should be changed to use standard colours, i.e. dark cyan for tasks. (Perhaps light cyan for the dependent task in the -P output.)