Issues with gcloud --entrypoint flag and F# type names

[absolutejam]

Howdy!

I've just begun playing with this suite of libraries and I've got a super minimal pub-sub function I want to deploy.

Unfortunately, I seem to have hit the snag wherein the full 'function' name which must be used is actually ClusterNotifications.Function+CloudFunction, where ClusterNotifications.Function is the module and the type is CloudFunction.

This is not allowed as:

ERROR: (gcloud.functions.deploy) argument --entry-point: Invalid value 'ClusterNotifications.Function+CloudFunction': Entry point name must contain only Latin letters (lower- or upper-case), digits, dot (.) and underscore (_), and must be at most 128 characters long. It can neither begin nor end with a dot (.), nor contain two consecutive dots (..).

This poses a bit of a blocker as F# type names as presented to C# may have symbols in them such as +, and this is not configurable (it's just for interop).

[absolutejam]

My example is here, if that helps: https://github.com/absolutejam/cluster-notifications

[jskeet]

Hmm. That's a really nasty one. That constraint around the entry point isn't anything I can control from this repo. I hope this is something that can be fixed relatively easily internally, but I don't know for sure.

What I could do within this repo is say "if the entry point contains an underscore, then try it with the underscore, but also try replacing the underscore with +". I'd rather not do that, but it's at least an option.

I'm on vacation until Monday, but I'll get in contact with the team and see what we can do.

[absolutejam]

Thanks for replying. I assumed it was coming directly from the cloud functions API, but I thought it was best to raise it here for awareness.

Thanks for your work on these libraries; I've been wanting to try out cloud functions with F# for a while but didn't want to deal with all the ceremony 👍

Enjoy the rest of your vacation 😄

[absolutejam]

After a suggestion from the F# slack, if I simply put my type in a namespace, it seems to work, as:

namespace Foo

type Bar () =
    // stuff...

Makes the type name Foo.Bar - The + is only present when a type is within a module.

Overall, it'd be nice to see the restriction removed, but perhaps this should be documented as a work-around for F#? It's not too much of a hinderance as I'm guessing any F# implementations would simply be providing a type as a wrapper for other functions anyway and I haven't looked at implementing a more idiomatic wrapper yet.

[jskeet]

Ah, that's really good to know, thanks. Yes, I'll document that once I've worked out where it should go :) (And I'd still like to get rid of the restriction, of course. Ideally I want to make the entry point optional anyway...)

[jchannon]

I've just hit this too.

[jskeet]

It looks like the restriction has now been lifted. I haven't tried with F#, but here's a C# example I've successfully deployed:

using Google.Cloud.Functions.Framework;
using Microsoft.AspNetCore.Http;
using System.Threading.Tasks;

namespace Issue179
{
    public class Outer
    {
         public class Function : IHttpFunction
        {
            /// <summary>
            /// Logic for your function goes here.
            /// </summary>
            /// <param name="context">The HTTP context, containing the request and the response.</param>
            /// <returns>A task representing the asynchronous operation.</returns>
            public async Task HandleAsync(HttpContext context)
            {
                await context.Response.WriteAsync($"Hello, Functions Framework from {GetType().FullName}");
            }
        }
    }
}

The entry point is Issue179.Outer+Function so that looks like it would work in the F# case too.