Disable .ps1 support in entryPoint about azure-functions-powershell-worker HOT 15 CLOSED

I guess our choices are:

• Don't support entrypoint at all.
• Copy the .ps1 file to a temp file and rename the extension to .psm1, then import-module the .psm1 file. This doesn't seem worth the effort.

I'm inclined to the first option. @tylerl0706 what's your thought?

from azure-functions-powershell-worker.

Entrypoint is a Functions concept and I think we should honor it if we can.

cc @asavaritayal @joeyaiello

from azure-functions-powershell-worker.

If we dot source and then run the function in the local scope, wouldn't that work?

pwsh.AddScript(". ./foo.ps1; Invoke-Foo", useLocalScope: true).Invoke()

from azure-functions-powershell-worker.

Then we cannot use AddCommand, which means we cannot differentiate between a hard exception (the script is broken) and an expected error because all kinds of errors will be written to error stream.

from azure-functions-powershell-worker.

Entrypoint is a Functions concept and I think we should honor it if we can.

I think it depends on whether it adds any value. What would be the scenarios for people to use an entry point along with a .ps1 file? A .ps1 file always has a default entry point.

from azure-functions-powershell-worker.

I thought we had pwsh.HasErrors available to us? Or is that set to true when there are errors in the error stream?

Also, using AddCommand(...).AddStatement() also has this problem with hard exceptions.

from azure-functions-powershell-worker.

As far as I understand, pwsh.HasErrors will be set to true if there is any error written to the error stream, which means the expected error will make it set to true too.

Didn't know the same issue happens to AddStatement() too. That's a shame 😦

from azure-functions-powershell-worker.

So get this, that actually does throw it looks like?

from azure-functions-powershell-worker.

Same with dot sourcing actually.

from azure-functions-powershell-worker.

I might be holding on to nothing here.

Feel free to change it (remove the EntryPoint support) if you think this is something user's won't want and we can get feedback later.

Please confirm with PMs though.

cc @asavaritayal @joeyaiello

from azure-functions-powershell-worker.

Hmm, thanks for verifying it. My memory was a bit off on this one. They have some different behaviors but I couldn't recall exactly what except that AddCommand("NonExistCmd") will throw while AddScript("NonExistCmd") doesn't.

Even with AddScript and dot-sourcing, passing arguments would be awkward. If using @args and AddArguments(..), you are basically assuming the parameter declaration is the in the same order of your passed-in arguments, which is fragile. And again, in my opinion, it's more work for a feature that is not reliable and of little value.

from azure-functions-powershell-worker.

ping PMs @asavaritayal @joeyaiello

from azure-functions-powershell-worker.

I just saw that we got some chatter about classes support. If we keep entryPoint, we can leverage it with classes no? That seems like a reasonable use case?

from azure-functions-powershell-worker.

I'm not sure we care about entrypoint right now, but I'll spin up an issue to discuss it, and then we can close this out if we determine it's useless over there.

from azure-functions-powershell-worker.

Closed via #116

from azure-functions-powershell-worker.