Add IEnumerable<T> support for arguments

[patriksvensson]

Would be nice if we supported passing multiple arguments to the Cake.exe.

cake.exe --foo=1 --foo=2 --foo=3

And allowed the user to resolve them all by resolving an IEnumerable like this:

var foo = Argument<IEnumerable<int>>("foo", Enumerable.Empty<int>());

Of course there would have to be safe guards in place to ensure that we throw if the user try to resolve a single argument where multiple has been passed and vice versa.

(Originally reported at http://stackoverflow.com/questions/35727010/how-do-i-pass-an-argument-that-is-a-string-array-to-my-cake-script)

[RichiCoder1]

Proper tokenizer time 😄? Would also be great to see switches (true, false) be an option
#317

[joaope]

Hi,

I'm about to spend some time on this feature but I don't want to go with implementing it without a couple of question:

1) The format.

Instead of this:

cake.exe --foo=1 --foo=2 --foo=3

Why not this:

cake.exe --foo=1 2 3

In my opinion it's much more readable, with lot less keystrokes and I guess this is the usual pattern for multiple command line arguments as well.

2) The options parser/tokenizer.

Have you guys ever considerer using commandline library to do the heavy job of parsing command line arguments? It's very concise and clean API, fully supported by the community since 2005. I've used it myself several times before for internal company tools and it works very well.

With a custom parser we're inventing the wheel here with such an easy-to-plugin API next door.

Haven't look into detail but it seems that plugging it in would be as easy as apply the Options attribute to CakeOptions. It supports several data type mappings, including Arrays and Lists. Oh, and switches :)

Cheers!

[patriksvensson]

Hello @joaope,

Great that you're thinking about contributing to Cake.
I'm at work and don't have much time but I'll try to answer your questions:

1. Using cake.exe --foo=a b c can mean a lot of different things depending on who you ask. Is b and c separate arguments? Initially I think the more verbose solution is the way to go for simplicity (implementation wise and to understand).
2. We prefer to keep the number of dependencies to a minimum. We already have a functional argument parser so we're not going to replace with a library at the moment.

Best regards
/ Patrik

[joaope]

@patriksvensson Hi :) thanks from the quick reply.

1. Following the current usage information b and c would be --foo related data right? Because an argument as to start with "-" or "--". My point is, at this stage we shouldn't be expecting anyone to ask what b and c are, we should actually define what they are because, well, we're adding a new feature. If it's usage is documented we can really go both ways.

Counting that you want to go with the verbose option and being arguments handled as an IDictionary<string, string> how would you tackle ICakeArguments. I'm talking about this particular interface because it seems the only one made available to the outside where one can not only modify the arguments list but retrieve them. In both cases arguments' values are being treated as strings.

2. Ok!

[gitfool]

I also thought that commandline was a good option if Cake was to improve it's command-line support. It's a bit confusing and inconsistent having different parameter passing done by PowerShell / Bash (in the bootstrapper) and then by Cake. It would be better if Cake did everything and the bootstrapper did nothing but bootstrap.

[fleed]

Any update on this one?

[markofranjic]

@patriksvensson any update regarding this feature? I have projects which I need that projects.
Many Nuget Sources
Many Replaces elements in web.config

Feature needs to support object

[patriksvensson]

@markofranjic Support for IEnumerable arguments will be available once #2334 have been merged into the codebase.

[patriksvensson]

Resolved in 1.0