Remove support for some experimental languages in 2.0

[davidebbo]

Our support for Python and PHP is too limited to be used beyond a demo. Even though we do mark it as experimental, we've found that users still try to build on them, leading to a poor experience (e.g. https://github.com/Azure/Azure-Functions/issues/419).

We can't change that in 1.0, but we do have the option of removing them in 2.0. We can then bring them back later when they are built on a proper model.

Let's discuss.

[johnpapa]

Is there a plan you can discuss for enhancing the experience for these technologies? Openly discussing the timing and roadmap will influence how some perceive this.

[davidebbo]

Generally, we are working on a new model for all languages that will use a persistent process to handle all requests (i.e. the way iisnode works today), instead of spawning a new exe on each request.

The first language that will follow this model will likely be Javascript, which currently runs in process in w3wp using Edge (problematic for a number of reasons).

@christopheranderson do we have any public writeup on the persistent process direction?

[lindydonna]

For some more context on this: for Python and PHP we use a scripting model and call out to e.g. python.exe. What we found is that even with the "experimental" label, customers still find the experience to be quite lacking. So, it's best to add Python back when we can do it the right way.

[fabiocav]

This is the main issue tracking the language extensibility work: https://github.com/Azure/azure-webjobs-sdk-script/issues/1319

Once that is in place, the goal would be to on-board additional languages using that model.

[paulbatum]

Best way to move forward with this is to remove the templates from the 2.0 branch in the templates repo. Filed https://github.com/Azure/azure-webjobs-sdk-templates/issues/550

[lindydonna]

@paulbatum The question is whether we want to remove the runtime support as well, for 1.0 customers who expect things to work.

[paulbatum]

Fair point, we would need to actively do work to block these scenarios from running on 2.0 and this should be discussed here.

[duncanmak]

I'm running the latest version (AFAICT):

Azure Functions Core Tools (2.0.0)
Function Runtime Version: 2.0.11308.0

And I noticed that func new only shows templates for C# and Javascript, and no F#.

[lindydonna]

@duncanmak We just haven't updated the F# templates yet. We're happy to take a PR if you'd like to contribute :)

https://github.com/Azure/azure-webjobs-sdk-templates/tree/v2.x

[operezfuentes]

MSFT guys, this is not the expected behavior for Python developers using Azure Functions as Serverless Framework. If something is marked as "Experimental" in version 1.0 is expected to be "Stable" or "Released" in version 2.0.

[paulbatum]

Hi Oscar, that would imply that no experiment ever fails. Surely you can agree this is not the case?

To be more specific, the approach we use to execute python functions today will never perform well. This just leads to customer dissatisfaction. We have a new language extensibility model that has good perf and we want python to use this model. Hence the removal of the old implementation in 2.0. We hope to bring python back on the new model sooner rather than later. In fact we are already talking with some internal teams about partnerships similar to what we did with the java tools team in devdiv to build java support on the new model.

So by all means, make some noise for python in functions 2.0 so that we can build a case for making this investment!

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Oscar Pérez notifications@github.com Sent: Thursday, October 5, 2017 11:03:05 PM To: Azure/azure-webjobs-sdk-script Cc: Paul Batum; State change Subject: Re: [Azure/azure-webjobs-sdk-script] Remove support for some experimental languages in 2.0 (#1744)

MSFT guys, this is not the expected behavior for Python developers using Azure Functions as Serverless Framework. If something is marked as "Experimental" in version 1.0 is expected to be "Stable" or "Released" in version 2.0.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-webjobs-sdk-script%2Fissues%2F1744%23issuecomment-334666351&data=02%7C01%7Cpbatum%40microsoft.com%7C5ab72d05530c48a8456708d50c7fe9b5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636428665875430423&sdata=EOSBNfiLOqZEAEZzy%2BS%2BX312ZOJEi7KO1s6SukcgrYU%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAApp-TrMVbRc7Q3pei66pq9de91_hTqks5spcKZgaJpZM4Oqeal&data=02%7C01%7Cpbatum%40microsoft.com%7C5ab72d05530c48a8456708d50c7fe9b5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636428665875430423&sdata=jXJH3VDZV%2FPH9YWW1902F6RWRQl%2F5CBvuQOnKx0yT%2F8%3D&reserved=0.

[operezfuentes]

Hi Paul, of course experimental can fails, but maybe this is not the case.

We are running Python Scripts (tunned to python 3.6, HTTP triggers and integrated with Azure AppLogic) in Azure Functions and runs well, certainly not performance, but it works. It's all we need for a managed service.

Some noise to support python in functions 2.0:

• Google Cloud Functions does not support python
• Azure Functions (2.0) will not support python
• Amazon Lambda supports python

It's a great competitive opportunity in order to retain Azure Customers. Please, does not obviate it.

[davidebbo]

@operezfuentes one thing to clarify is that the 1.x version is not going away anytime soon. So if you're happily using Python today, that will continue to work for the foreseeable future. So the fact that 2.0 won't initially have it will not affect you.

[dirkesquire]

Please do not remove support for Python. It works pretty well. We just need a selector to choose python2 or python3 versions upon creation of the function.

The capacity already exists to pip install python modules using Kudu, so no problems there.

As people in the python community are preparing to end-of-life python 2.7, the ideal choice is to start gearing up new Azure Functions 2.0 to default to python 3.x as the default.

[davidebbo]

@dirkesquire please see my previous comment. It's not getting removed from v1, and v2 will have a better one.

[dirkesquire]

Yes, well of course I have read it. Unfortunately the title of the this github issue is 'Remove support for some experimental languages in 2.0', which I am just weighing in on.

I'm just trying to encourage people to please continue work with this feature as the Python community really appreciates it!

I do think that the improvements that you mention of using a persistent model to spin up requests is an exciting prospect, because a new python instance per request is not great.

Thinking about how things work currently, I know we can easily install Python3 using the extension menu and that works well. What I would really love is to be able to append to the %PATH% variable in the Platform Overview, Application settings, so then we can point to the python installation path we installed via the Extension menu. This is so that it is persistent when the service reboots etc and this gets read on bootup. This also saves people from having to faff about in Kudu because it can all be done in the Azure portal. Currently there is a path to an old version of Python2 baked in by default into %PATH%, and that is not pleasant, which would be nice if it could be removed. The same issue exists when one uses python on Azure AppServices. I can appreciate this suggestion might not be relevant to your new model, but I do encourage Python3 to be the default for your new Azure Functions 2.0 since you are effectively doing a clean break in versions.

[davidebbo]

@dirkesquire see https://github.com/Azure/azure-functions-host/wiki/Using-a-custom-version-of-Python for a workaround.