Skip to content

Authoring & Testing Language Extensions

Christopher Anderson edited this page Jan 23, 2018 · 18 revisions

This article is a work in progress. The instructions will change frequently, so please check back if you have any issues.

Authoring config driven language provider

structure

Your langue worker needs to be in a directory named the same as the Language property (i.e. "python"). Inside the directory there needs to be your worker.config.json and the files needed to run your language worker

Example:

(root) (i.e. "C:\temp\workers")
| python
|| worker.config.json
|| worker.py

worker.config.json

Your worker.config.json is a file that tell the Functions host how to start your language worker

Example:

{
    "Description":{
        "Language":"python",
        "Extension":".py",
        "DefaultExecutablePath":"python",
        "DefaultWorkerPath":"worker.py"
        
    },
    "Arguments":[]
}

It has two sections: Description and Arguments. It's important not to include any other settings than what is shown in the example.

Description has 4 arguments that are used to determine when to use your language worker and how to start it.

  • Language: this is your language descriptor. It doesn't actually need to match the language (You could name your python worker "python-beta1"). All characters need to be lower case and the directory name also needs to be lower case.
  • Extension: this is the file extension your provider will be used for. (i.e. '.py' or '.test.py')
  • DefaultExecutablePath: this is the executable that will be invoked, generally it is found on the PATH, but an absolute path can be used, if necessary (but probably shouldn't ship like that...) (i.e. "python" or "node")
  • DefaultWorkerPath: This is the entry point for your worker. It will be passed in as the first argument (i.e. "worker.py" gets passed in with a fully qualified path "python C:/temp/workers/python/worker.py")

Arguments is an array of strings that is can be used to specify additional arguments after the filename

Testing

Dependencies

  • dotnet 2.1.2
  • whatever framework you're using on PATH (i.e. python)
  • download latest "Functions.Private.xxx.zip" from engineering/generic-language-worker branch (should be here)
    • You can alternative run everything from source code. Instructions for that are here.
    • be sure to unzip it somewhere you'll find it
  • your implementation of the language worker
  • a sample Function App project to run

Instructions

  • Set your environment variables (either globally or in your terminal session)
    • AzureWebJobsScriptRoot is the path to your Function App project (i.e. your sample code you're testing with)
    • workers:config:path is the path to your workers (i.e. "C:\temp\workers" which contains your worker "C:\temp\workers\python")
  • start the host
    • from the "Functions.Private..." directory you unzipped earlier, go to "SiteExtensions/Functions"
    • dotnet .\Microsoft.Azure.WebJobs.Script.WebHost.dll

Logs

  • Some logs will show up in your stdout, but most end up in log files that are under $TEMP/Functions/
  • Host logs (which will tell you if there was a problem with your config/etc.) are under Host
  • worker logs are under Worker and your Language property in your config will determine the directory name

Learn

Azure Functions Basics

Advanced Concepts

Dotnet Functions

Java Functions

Node.js Functions

Python Functions

Host API's

Bindings

V2 Runtime

Contribute

Functions host

Language workers

Get Help

Other

Clone this wiki locally