Azure-functions-core-tools: Easy install of the functions core tools

[asavaritayal]

Today, working with Java functions locally requires a pre-installation of dotnet and node. This is a point of churn for existing Java and potential Python developers.

We want a cleaner experience for installing:
[P0] Functions CLI
[P1] Binding extensions

Proposed Experience

Windows

• [x] npm install -g azure-functions-core-tools@core
• [x] choco install azure-functions-core-tools

Linux

• [x] apt-get install azure-functions-core-tools
• [x] yum install azure-functions-core-tools

MacOS

• [x] brew install azure-functions-core-tools

Open Questions

https://github.com/Azure/azure-functions-cli/issues/367
The only scenario that requires dotnet executable to be on the machine is that of installing extensions because we launch using
dotnet add extensions.csproj package <extension> --version <version>

Couple of options are:

1. Explicitly require the user to install dotnet to work with bindings
2. Do a silent install of dotnet along with the core tools

[jeffhollan]

The Azure Functions host runtime is also in dotnet core so may mean regardless of bindings or not they may need it pre-installed? Not sure - but maybe we can install dotnet core without requiring them to do it manually.

Also may swap the priorities (also think they are orthogonal). We have a "reasonably" workable solution for installing CLI cross-platform, but binding extensions today (which also incorporates triggers) is dicey/confusing. But I think that may be seperate from this issue.

Only other thought is one concern with list above is it's a lot of tools we have to learn and maintain - and each has it's own quirks to learn for a new developer. I almost wonder if we'd get more bang for our buck by doing 2 initially - a .msi for windows and a .dmg for mac.

[ahmelsayed]

We can have a self-contained build of the CLI that includes .NET runtime with it. That way users don't have to install .NET on their machines if they don't want to.

The way I look at it is the fact that the runtime is implemented in .NET _should_ be just an implementation detail and not something in your face all the time especially if you are not a dotnet dev. I know I have had some push back on this before, so let me know if you disagree.

I already enabled self-contained builds for the cli in c5f836402600addc33d7b0f8203a8a8ed421e833 and you can give the packages here a try https://ci.appveyor.com/project/appsvc/azure-functions-cli/branch/master/artifacts. These builds don't require dotnet core to be installed on the machine because it's bundled with the cli.

I tested the Linux and Windows ones so far.

For Linux, I don't think there is any natural way of installing other than through the distro package manager anyway.

between homebrew or a pkg for mac (I don't think a dmg would work since you need to put ./func on the path) I don't have a preference, mainly since MacOS doesn't have an official package manager. same with Windows.

[ahmelsayed]

remaining workitems for the self-contained CLI:

• [ ] automate signing non-Windows binaries
• [ ] remove func extensions commands dependency on dotnet executable

[ahmelsayed]

/cc @watashiSHUN since he's working on the linux packages

[asavaritayal]

/cc @hexiaokai , @selvasingh who inquired about this in the context of Java

[asavaritayal]

Since .NET core is unavailable via homebrew today, we cannot do a direct brew install of the functions core tools. In this event, we have two options:

Option A: Enable homebrew install from a private branch.

1. brew tap Azure/Functions
2. brew install azure-functions-core-tools

Once .NET core is available via homebrew, we can simply remove step 1.

Option B: Offer a core-tools-installer.pkg for manual downloading and installation.

My suggestion is A as it provides managed options such as brew update/upgrade, and points in the direction of our long term goal to support homebrew.

@ahmelsayed, @watashiSHUN, @jeffhollan , @fiveisprime - would be good to get your opinion.

[ahmelsayed]

I like option A more, specially since @watashiSHUN has it mostly done. We just need to create Azure/homebrew-azure-functions, right?

[watashiSHUN]

+reference https://github.com/Homebrew/homebrew-core/pull/24576
correct, but I don't have permission to create repo under Azure, also we need to agree on a name,
for brew tap Azure/azure-functions repo name ==> homebrew-azure-functions:

If it’s on GitHub, they can use brew tap user/repo, where user is your GitHub username and homebrew-repo your repository.

[ahmelsayed]

@watashiSHUN I just created https://github.com/Azure/homebrew-functions please use if for this

[ahmelsayed]

It looks like homebrew works now!

brew tap azure/functions
brew install azure-functions-core-tools

[watashiSHUN]

For ubuntu here is the instruction:

1. Register the Microsoft Product key as trusted.

   curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
   sudo mv microsoft.gpg /etc/apt/trusted.gpg.d/microsoft.gpg
   

2. Set up the desired version host package feed.

   Ubuntu 16.04 / Linux Mint 18

   sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-ubuntu-xenial-prod xenial main" > /etc/apt/sources.list.d/dotnetdev.list'
   sudo apt-get update
   

3. Install Function CLI.

   sudo apt-get install azure-functions-core-tools
   

[ahmelsayed]

I made a PR with an updated README with those 2 methods that now work take a look at #395 or the final README here

[ahmelsayed]

@watashiSHUN any ETA for rest of debian and yum packages?

[watashiSHUN]

rest of debian is done

[fabiocav]

@ahmelsayed let’s chat about the extension command dependency on dotnet. Whatever we do, I’d like to make sure it’s consistent with the runtime and have some ideas on how to approach this.

[MV10]

Casting a 👍 vote for a Windows msi as suggested by jeffhollan earlier!

Today, working with Java functions locally requires a pre-installation of dotnet and node. This is a point of churn for existing Java and potential Python developers.

Also churn for any Windows .NET developer who doesn't share the recent fascination with memorizing endless stacks of command-line tools and switches. I use IDEs for the same reason I don't write code in Notepad (or the Azure Portal, which is approximately the same thing, come to think of it).

I was initially a little surprised to see node chosen over your very own NuGet, but I suppose node can execute installer-style actions which I don't think is an option with NuGet packages. (I suppose that's where choco comes in... some days I feel like I spend more time juggling tools than I do writing code.)

Anyway -- is msi a realistic option?

[watashiSHUN]

@MV10
azure-functions-core-tools is available on chocolatey:
try: choco install azure-functions-core-tools
or choco install azure-functions-core-tools --pre for 2.0.0 (beta)

[MV10]

@watashiSHUN I'm trying to be _less_ dependent on CLIs. Had enough of that in the 70s and 80s, thanks. :)

[watashiSHUN]

I see, although I would argue that msi might not be necessary since func itself is a CLI, you will need to work with the command line nevertheless. Maybe you are thinking more of integration with IDEs like eclipse/IntelliJ?

[MV10]

Yes, a little IDE we call Visual Studio. :)

But it turns out the troubles that led me here are related to an open issue about keeping the VS extension in sync with Function host changes: https://github.com/Azure/Azure-Functions/issues/745#issuecomment-378323916

[snoopdouglas]

rest of debian is done

I can't see any repository listed for Debian in the readme. Xenial's package seems to work for it though.

[watashiSHUN]

@snoopdouglas here is the full doc

[snoopdouglas]

@watashiSHUN There is no Debian-specific repository mentioned there either. Perhaps add a note explaining that the Ubuntu ones are fine to use (if you can verify that applies to most Debians)?

[ahmelsayed]

closing as this is done