Add support for CLI creation of new functions based on order, without explicit naming.

[t-eckert]

Is your feature request related to a problem? Please describe.

The CLI provides a way of creating new Azure Functions following this sample structure:

cargo func new http --name foo --auth-level anonymous

It may be a useful addition to the user experience to allow for these name and auth_level parameters to be passed in without explicitly naming them, and assigning them based on the order in which they are provided. The following command would produce the same result as the above:

cargo func new http foo anonymous

Describe alternatives you've considered

All Azure Functions do require a name parameter. An alternative design that may be used is to resolve the first arg to always be the name param and have additional params be explicitly named. i.e.:

cargo func new http foo --auth-level anonymous

Additional context

It will be worth looking at how this is implemented in the Azure Functions CLI.

[peterhuene]

I think the name should be a positional arg, but things like the auth level should be an option (otherwise ordering would need to be defined).

The name has precedence with cargo func new-app and cargo new.

cargo func new http foo and cargo func new http --name foo should both ideally work (for back compat), but cargo func http foo --name bar should be an error. Plus there should be at most one positional arg.

[ajnirp]

I played around with the Azure Functions CLI implementation (it doesn't seem to support positional args at all) and read this thread. Thoughts:

1. Agreed that there should be at most one positional arg - otherwise it's troublesome to remember the CLI invocations for functions like ServiceBus (5 required args) or CosmosDB (4 required args).
2. name is the only required arg common to all functions, so it deserves to be the sole positional arg (besides the function template).
3. "but cargo func http foo --name bar should be an error" -> clarifying, did you mean to write "but cargo func new http foo --name bar should be an error"?

Also, if no one is else is working on this, I'd like to take it up.

[peterhuene]

@ajnirp you are correct! Thanks for offering to take it up; let me know if there's anything I can help with.

This should target the dev branch. The durable-functions branch is the only other active feature branch at the moment, which is a major work-in-progress.

[ajnirp]

I was poking around and I'm failing to see changes I made in azure-functions-sdk/.

My workflow is:

1. Make changes to the help message string in new/http.rs.
2. Rebuild azure-functions with cargo build.
3. Run cargo func new-app hello.
4. Add "hello" to the Cargo.toml in the root folder.
5. cd hello/ Edit the Cargo.toml file to point to the local azure-functions build like so: azure-functions = { path = "../azure-functions" }.
6. Run cargo build.
7. Run cargo func new help http. At this point I expect to see the modified help message. I see the old one instead.

Could use some help on this - any idea what I'm doing wrong?

[peterhuene]

Hi @ajnirp! When testing out changes to the SDK, you'll need to install the local version using cargo install -f --path ./azure-functions-sdk. This should build and install the local SDK with your changes and you should immediately see your changes to cargo func applied.

[ajnirp]

Thanks @peterhuene! That worked. If I understand correctly, the problem with not running cargo install is that when I was running cargo func, it was running against some kind of user profile-level Cargo cache, and ignoring the local build I had?

Re: the issue - I browsed the Clap docs and I think I'm missing something very obvious - how to make an arg act as both a positional arg as well as an option arg.

An alternate approach is to make two different args, one positional and one option-style, and specify that one conflicts with the other. This seems hacky, but it works. Here's the relevant code - ajnirp@ca672e8

Is there a specific approach you would suggest?

[peterhuene]

If I understand correctly, the problem with not running cargo install is that when I was running cargo func, it was running against some kind of user profile-level Cargo cache, and ignoring the local build I had?

That's correct. cargo only searches its installed tool path for commands, so cargo func was using a previously installed SDK.

Is there a specific approach you would suggest?

I don't think you'll be able to have one argument function as both an option and a positional argument. I think the solution you have that uses two different options will work just fine.

[peterhuene]

Resolved with #403.