I have incorporated feedback by renaming the function and changing up the parameters.

function emitterFor(fn: TransportFunction, options = { binding: HTTP, mode: Mode.BINARY }): EmitterFunction

PTAL

Definitely not requesting changes. Thanks for the detailed explanations.

No worries. I should have been more explicit in the PR description.

I guess why do we have a custom emitter at all?

I'm not sure what you mean by "custom emitter". This PR is about removing opinionated choices like the use of axios to send messages across the wire, and replacing it with something that is less "custom".

We should let users BYO / use your own libraries for emitting using raw primitives of HTTP (headers and body).

That is already possible. Perhaps you don't recall some of the conversations around this, or are not familiar with the codebase. It landed in this PR. Your hypothetical is available today, it just looks a little different.

const axios = require('axios').default;

const ce = { ... }
const message = HTTP.binary(ce); // Or HTTP.structured(ce)

axios({
  method: 'post',
  url: '...',
  data: message.body,
  headers: message.headers,
});

This PR is about providing users a way of encapsulating behavior. Imagine the user is not using axios, but instead their application has chosen superagent. Sending a Message looks a little different, and it's just clunkier.

import request from "superagent";

const ce = { ... }
const message = HTTP.binary(ce); // Or HTTP.structured(ce)

const post = request.post('...');
for (const key of Object.getOwnPropertyNames(message.headers)) {
  post.set(key, message.headers[key]);
}
post.send(message.body);

This PR would make that look a little different.

// Same code as above but wrapped in a function
// User code - a transport function
function sendViaSuperagent(message) {
  const post = request.post('...');
  for (const key of Object.getOwnPropertyNames(message.headers)) {
    post.set(key, message.headers[key]);
  }
  post.send(message.body);
}

// The returned EmitterFunction handles converting from CloudEvent to Message and invokes 'sendViaSuperagent`
const emit = emitterFor(sendViaSuperagent);

const ce = { ... }
emit(ce);

This encourages encapsulation. For example, HTTP.binary(ce) is only called in one place in the code. Any specific properties or other attributes that a user may need to provide to axios, superagent or got or whatever is being used are all encapsulated in this one function.

Additionally, and probably more important, we have talked about adding multiple additional transport support soon. This would mean that, for example, MQTT would look similar.

// This is user code - a TransportFunction
function sendMQTT(message) {
  // do whatever you need to do with message.body and message.headers to send it over MQTT
}

// Create an EmitterFunction
const emit = emitterFor(sendMQTT, { mode: Mode.BINARY });

const ce = { ... };
emit(ce);

Note that this looks exactly the same as sending an event over HTTP. That's by design. In fact, I can use the EmitterFunction interface in my shiny new TypeScript application for CloudEvents. Imagine that you want to build an app that allows devs to provide a EmitterFunction so that it can emit events on their behalf. This makes that possible, and it won't matter what they are doing to actually send the event across the wire - HTTP/MQTT/ProtoBuff/whatever.

Sure, it's a small benefit to the user to provide this. But I don't understand your hostility towards it, especially given that we can already do what you were asking for in the very trivial case of just sending an event with axios.

I'd rather expose just 1 interface for users to emit CloudEvents

I'm not proposing more than 1 interface. As I have said multiple times, Emitter is meant to be removed in v4.0.0. I am proposing a replacement that does not have a dependency on a 3rd party transport library such as axios.

Emitter.send(ce, "https://cloudevents.io/example");

This means that we would not be removing the dependency on axios. Is that what you are suggesting? I understood that removing this dependency is a goal for the v4.0.0 release.

@grant the purpose of this PR is to provide a mechanism in 4.x for users to send events across the wire without this module having an explicit dependency on axios (or any other transport module). The Emitter capabilities as they are now with an explicit dependency on axios will go away. But it would still be nice to provide a simple mechanism for users to easily send events.

I can appreciate some of the usefulness for this utility, but I don't think a stateful emitter factory should be part of the SDK.

The factory is not stateful. But maybe you mean the emitter itself. As I see it, if we want the user to not have to provide the transport binding and serialization mode with every call there must be some state. Otherwise, with each function call that sends an event, the user would be required pass HTTP and Mode.BINARY (or Mode.STRUCTURED) in addition to the event.

It's really hard to discuss design decisions in the abstract, so in the PR description, can you write up the before and after with these changes?

Done.

I think I can suggest a different way to achieve the same result without a factory.

OK - let's hear it.

I can imagine a developer writing their own factory pattern that is even more flexible than the interface here. For example, a user could just write a wrapper for the emitter function and add extra params.

The whole point is that the Emitter as it is today is going away.

In terms of interface design, Factories are more common in Java and less so in Node.

Ahh but using closures to maintain state is quite a popular JavaScript style. I thought you'd like it. How about I rename it to emitterFor( fn: TransportFunction, options: Options ) : EmitterFunction? Then we won't think of it as a factory.

There was a typo in the upload part of the CI. Also, there was a section that (thankfully) did not run, which would have created a second release. Moved the release-please action later in CI so less time elapses between the creation of the release, and the upload of the binaries.

Signed-off-by: Lance Ball [email protected]

:robot: I have created a release *beep* *boop*

0.7.0 (2020-09-24)

Features

• add local debugging to node.js templates (#132) (1b0bb15)
• decouple function name from function domain (#127) (0258626)
• default to no confirmation prompts for CLI commands (566d8f9)
• set builder images in templates and .faas.yaml (#136) (d6e131f)
• ci/cd: add release-please for automated release management (8a60c5e)

Bug Fixes

• correct value for config path and robustify (#130) (fae27da)
• delete command (284b77f)
• describe works without Eventing (6c16e65)
• sync package-lock.json (#137) (02309a2)

This PR was generated with Release Please.

@lance Does it make sense to only have 1 parameter(an option object) passed to the emitterFactory? Then we could easily default values.

@lholmquist I could make that change. Something like this?

const emit = emitterFactory({ binding: HTTP, mode: Mode.BINARY, transport: axiosEmitter });

With binding and mode defaulting to HTTP and Mode.BINARY respectively, the above is equivalent to:

const emit = emitterFactory( { transport: axiosEmitter } );

Personally, I think I'd prefer two parameters: the function and an options object. E.g.

const emit = emitterFactory( axiosEmitter, { binding: HTTP, mode: Mode.BINARY });

Which makes the default call a little cleaner.

const emit = emitterFactory( axiosEmitter );

This is specifically to support the existing behavior as it is today with Emitter. Since a user can specify the serialization mode (BINARY or STRUCTURED), with the current Emitter.send(), we need to have one of each kind of emitter.

This code should all be removed with 4.0.0 given that it's currently deprecated.

This commit adds a .builder.yaml file to each template directory. In the file there is at the moment a single key/value pair, "default: <image>", where the actual builder image name is <image>. Using a mapping allows the future possibility that a user may specify a builder image by name via a flag on the command line.

When a project is initialized, the .builder.yaml file is read, and the default builder is saved in the project's .faas.yaml file. The .faas.yaml file is then consulted when building an image with faas build. If the builder image is specified, then the builder will use it. Otherwise, it will fallback to the defaults. This allows developers to create custom builders, and specify them in the configuration file.

An open question is whether the .builder.yaml file should be deleted after it is read during project initialization. The init command is the only time the file is consulted, and it may be confusing for the user if they discover a second configuration-y file in the project directory.

Fixes: https://github.com/boson-project/faas/issues/120

The buildpack Runtimes are all currently hard coded.

https://github.com/boson-project/faas/blob/566d8f9255d532e88e72d5bce122bebaee88bc81/buildpacks/builder.go#L25-L29

It would be nice for this to be configurable.

We should probably implement the default domain as .cluster.local suffix for users initializing a Function without an explicitly provided name nor name derivable from directory structure, rather than generate an error or force the input. For example

$ cd /home/alice/projects/test
$ faas create
OK test.cluster.local

(Currently this use case generates an error later in the process, on deploy)

For a little background: when creating a new Function, the primary use case is creating services with fully qualified domain names which are routable from localhost (i.e. ending in a TLD+1 public suffix)

For example, to create the following Functions:

www.example.com
my.example.com
cdn1.us-west2.example.co.uk

Is accomplished by either using the suggested project directory structure:

projects
├── example.co.uk
│   └── cdn1.us-west2
└── example.com
    ├── my
    └── www

or by explicitly providing the names

faas create www.example.com
faas create my.example.com
faas create cdn1.us-west2.example.co.uk

However, we do not yet support:

faas create test
OK test.cluster.local 

I've incorporated all of the feedback @zroubalik @matejvasek - ty!

Uses the Cobra "Long" configuration for each command to provide more descriptive text.

Example:

faas help create                                                                                                      1.3m  Mon 21 Sep 2020 09:55:40 PM EDT
Create a new Function, including initialization of local files and deployment

Creates a new Function project at 'path'. If 'path' does not exist, it is
created. The function name is the name of the leaf directory at path. After
creating the project, a container image is created and is deployed. This
command wraps 'init', 'build' and 'deploy' all up into one command.

The runtime, trigger, image name, image repository, and namespace may all be
specified as flags on the command line, and will subsequently be the default
values when an image is built or a Function is deployed. If the image name and
image repository are both unspecified, the user will be prompted for a
repository name, and the image name can be inferred from that plus the function
name. The function name, namespace, image name and repository name are all
persisted in the project configuration file .faas.yaml.

Usage:
  faas create <name> [options] [flags]

Flags:
  -c, --confirm             Prompt to confirm all configuration options - $FAAS_CONFIRM
  -h, --help                help for create
  -i, --image string        Optional full image name, in form [registry]/[namespace]/[name]:[tag] for example quay.io/myrepo/project.name:latest (overrides --repository) - $FAAS_IMAGE
  -n, --namespace string    Override namespace into which the Function is deployed (on supported platforms).  Default is to use currently active underlying platform setting - $FAAS_NAMESPACE
  -p, --path string         Path to the new project directory - $FAAS_PATH (default "/home/lanceball/src/go/src/github.com/boson-project/faas")
  -r, --repository string   Repository for built images, ex 'docker.io/myuser' or just 'myuser'.  Optional if --image provided. - $FAAS_REPOSITORY
  -l, --runtime string      Function runtime language/framework. - $FAAS_RUNTIME (default "go")
      --templates string    Extensible templates path. - $FAAS_TEMPLATES (default "/home/lanceball/.config/faas/templates")
  -t, --trigger string      Function trigger (ex: 'http','events') - $FAAS_TRIGGER (default "http")

Global Flags:
      --config string   config file path (default "~/.faas/config")
  -v, --verbose         print verbose logs

Signed-off-by: Zbynek Roubalik [email protected]

Fixes: #123

faas create foo -l node

Creates a new directory foo and initialize/create the function inside.

A directory structure is created according to the specified name, eg. relative/path/to/foo, /absolute/path/to/foo, foo or empty value (in this case it uses current directory).

The 'last' directory name is used as function name.

Currently, the CLI has been written to conflate the function name with the function domain. For example, creating a project in a directory, foo, produces the following:

❯ ../faas init -l node                                                                                                         Wed 16 Sep 2020 09:49:18 AM EDT
Project path: /home/lanceball/src/go/src/github.com/boson-project/faas/foo
Project name: foo.faas.boson-project.github.com
Runtime: node
Trigger: http

Where the project name has been derived from the local directory. It is possible to provide a name to the init and create commands. For example,

❯ faas init foo -l node                                                                                                541ms  Wed 16 Sep 2020 09:51:01 AM EDT
Project path: /home/lanceball/src/go/src/github.com/boson-project/faas/foo
Project name: foo
Runtime: node
Trigger: http

However, this produces problems during deployment.

❯ faas build                                                                                                           545ms  Wed 16 Sep 2020 09:52:07 AM EDT
A repository for Function images is required. For example, 'docker.io/tigerteam'.

Repository for Function images: docker.io/lanceball
Building image: docker.io/lanceball/foo:latest

faas/foo on  main [$!?] is 📦 v0.1.0 via ⬢ v12.16.3 took 35s 
❯ faas deploy                                                                                                          35.8s  Wed 16 Sep 2020 09:52:48 AM EDT
Error: : Invalid value: "foo": should be a domain with at least two segments separated by dots

This is, of course, going to be confusing to the end user. "I just wanted to name my function something. Why is it failing?".

In fact, if I manually edit ./.faas.yaml to attempt to comply with the error message suggestion, I then get the following.

❯ cat .faas.yaml                                                                                                        5.1s  Wed 16 Sep 2020 09:54:25 AM EDT
───────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: .faas.yaml
───────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ name: foo.bar
   2   │ namespace: ""
   3   │ runtime: node
   4   │ image: docker.io/lanceball/foo:latest
   5   │ trigger: http
───────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

faas/foo on  main [$!?] is 📦 v0.1.0 via ⬢ v12.16.3 
❯ faas deploy                                                                                                          147ms  Wed 16 Sep 2020 09:54:30 AM EDT
Error: invalid service name 'foo.bar', must be at least three parts.

Not only is it unintuitive to conflate domain and name, it can cause real usability issues, and complicates our code base. It also ignores the fact that a function may move from domain to domain as it goes through a development/test/stage/prod pipeline. Additionally, domain management is really the baliwick of cluster configuration, and in the vast majority of cases, these two personas (developer / cluster admin) are going to be different people.

While it is true that a function's name ultimately does become a part of the route, this should not be a concern of the function developer. For example, using the kn CLI, it's easy to create a function named foo. The route to the function ultimately does contain that name, but as a developer, I don't really care as long as the route is available.

❯ kn service create foo --image docker.io/lanceball/foo:latest                                                         152ms  Wed 16 Sep 2020 10:00:20 AM EDT
Creating service 'foo' in namespace 'faas':

  0.037s The Configuration is still working to reflect the latest desired specification.
  0.286s The Route is still working to reflect the latest desired specification.
  0.587s Configuration "foo" is waiting for a Revision to become ready.
 12.846s ...
 12.883s Ingress has not yet been reconciled.
 12.937s unsuccessfully observed a new generation
 13.139s Ready to serve.

Service 'foo' created to latest revision 'foo-jfcdt-1' is available at URL:
http://foo.faas.127.0.0.1.nip.io

I recommend a change to effect the following.

• Derive the function name from the directory path if not provided (exists already), but limit it to the directory name instead of the full path
• Allow user to provide a name for init and create commands (exists already)
• Since kn names cannot have a . in them, continue to munge the name so that we prevent the user from experiencing an error if they name the function foo.bar for example. In that case, we can munge it to foo-bar and kn will be happy.

See: https://github.com/boson-project/faas/issues/47 See: https://github.com/boson-project/faas/issues/107 See: https://github.com/boson-project/faas/issues/94 See: https://github.com/boson-project/faas/issues/95 See: https://github.com/boson-project/faas/issues/86 See: https://github.com/boson-project/faas/issues/85

Note all of these issues are directly related to naming and DNS of functions. If we simply assume that the cluster is configured correctly, and ensure that any name provided or derived does not have a . in it, all of these issues essentially go away.

@boson-project/core we discussed this earlier in the week, please feel free to include your thoughts here.

This commit adds a .builder.yaml file to each template directory. In the file there is at the moment a single key/value pair, "default: <image>", where the actual builder image name is <image>. Using a mapping allows the future possibility that a user may specify a builder image by name via a flag on the command line.

When a project is initialized, the .builder.yaml file is read, and the default builder is saved in the project's .faas.yaml file. The .faas.yaml file is then consulted when building an image with faas build. If the builder image is specified, then the builder will use it. Otherwise, it will fallback to the defaults. This allows developers to create custom builders, and specify them in the configuration file.

An open question is whether the .builder.yaml file should be deleted after it is read during project initialization. The init command is the only time the file is consulted, and it may be confusing for the user if they discover a second configuration-y file in the project directory.

Fixes: https://github.com/boson-project/faas/issues/120

If you have some time to read the history, I recently introduced a PR that removed --path altogether from almost all commands, leaving it only for init and create as a required argument. But that PR was closed as seeming less scriptable.

I am happy to reconsider this. My thinking was that if all commands are executed from within the context of a project directory, there is no need for a --path argument except when creating a project. Given that the PR was reverted, all commands now have --path as a flag, and init and create have <path> as a required argument. I wouldn't mind seeing --path go away, but I'd prefer not to make <path> in create and init a required flag. Maybe it's irrational, but I just don't like required flags. :smiley:

I know! It's super frustrating. At one point, early on in this project, I was using --tag similar to Docker, which considers the entire string of registry/user/repository:tag to be the --tag. But we reverted.

As it stands now, "image name" specified by --image is the full string registry/user/repository:tag, and repository is registry/user. I would love to normalize this usage based on existing tooling in the wild, but it's not really clear how to best go about that given that each registry may have different URLs. For example, Docker supports docker.io/node:latest (no user in this case).

tbh, I question the usefulness of a faas create that does scaffolding and then an intermediate build afterwards

I am with you on this. I believe @zroubalik and @matejvasek are as well. But we'll have to convince @lkingland and @nainaz.

Instead I would love to see non-overlapping commands, that do:

• Scaffolding (init or maybe create but only for creating the repo)
• Building (build)
• Deploy (deploy)
• Run locally (run)

This already exists in what we have today. It's just that there is an additional create command.

Yes, <path> is mandatory here and may be . - at least when this lands.

You make a good point here.

Note: added tests include testing for Axios, SuperAgent and Got as HTTP transport libraries.

This commit adds an emitterFactory function that returns an EmitterFunction object. The EmitterFunction may be used to emit events over a supported network transport layer. Currently, only HTTP is supported.

Parameters provided to the emitterFactory are the transport Binding (only HTTP supported), the encoding mode (Mode.BINARY or Mode.STRUCTURED), and a TransportFunction.

The implementation for emitBinary and emitStructured has been replaced with this simple pattern and those two functions have been removed.

Example:

// The endpoint URL that will receive the event
const sink = 'https://my-event-sink';

// A function that uses Axios to send a message over HTTP
function axiosEmitter(message: Message, options?: Options): Promise<unknown> {
  return axios.post(sink, message.body, { headers: message.headers, ...options });
}

// Create an event emitter
const emit = emitterFactory(HTTP, Mode.BINARY, axiosEmitter);

// Emit an event, sending it to the endpoint URL
emit(new CloudEvent{ source: '/example', type: 'example' });

Related: https://github.com/cloudevents/sdk-javascript/issues/314

For all of the REQUIRED context attributes in the spec, it's pretty clear that their values cannot be null, based on wording that @duglin pointed out.

• Constraints:
  • REQUIRED
  • MUST be a non-empty URI-reference
  • An absolute URI is RECOMMENDED

For OPTIONAL context attributes, the wording admittedly is a little less clear.

• Constraints:
  • OPTIONAL
  • If present, MUST adhere to the format specified in RFC 2046

What does it mean to be "present"? For the typed representation of a CloudEvent in an SDK, this depends on the language and idiomatic style. It is an SDK question and may differ across the various languages. In JavaScript, for example, this is totally valid.

const event = new CloudEvent({ source: '/example', type: 'example' });
console.log( event.datacontenttype ); // has not been set, will print 'undefined'

The datacontent type attribute is present on the event object. Heck it's JS, so event.foobar is also "present" in a certain sense, as it will also return undefined. (We could get into Object.hasOwnProperty(), but that's a digression).

Where this question of being present matters is in the representation on the wire - e.g. in JSON or Avro format. Now, when we ask if an attribute is "present", it seems a bit clearer. I read it as, "does the context attribute exist at all in the JSON representation?" If so, then it must be in RFC 2064 format - - which null is not.

To continue with the JS example, if I convert the event into JSON format, we don't see the datacontenttype attribute.

event.toString()
> '{"id":"2985acb6-d7b9-49b6-aad7-b5b4dae8a2dd","type":"example","source":"/example","specversion":"1.0","time":"2020-09-23T14:25:46.583Z"}'

If the datacontenttype attribute were printed and it had an empty value, I would consider that an error based on my reading of the event and JSON format specs.

@grant the proposal was that Emitter is being deprecated because of the work that was done with the Message and Binding interfaces, etc. But, I've been thinking about this. I think before we drop 4.x, we should have a good, easy to use replacement, because it really does make life easy. Here is a prime example in the Knative docs (using the 2.x API).

@lholmquist are you good with holding off a bit on 4.x? I'm noodling something like an EmitterFactory that takes a Binding, SinkUrl, Mode and a function and does the right thing. I'm a little stalled on it at the moment. Will try to get a WIP PR submitted soonish.

Any suggestion?

I've been sitting here for 5 minutes trying to come up with a good name. I see why you asked. The best I've come up with is providedOrConfiguredName(string) string. But meh.

@zroubalik is it just habit that you used --signoff? Do you think having something like the DCO bot here is useful?

Signed-off-by: Zbynek Roubalik [email protected]

Is there a specific reason for us to stay on go 1.13? go 1.15 is already out. So updating to 1.14 for now.

Oops!

@zroubalik thanks for your feedback. I've incorporated it.

Allow commands such as .help only when the repl is not in multiline mode, preventing erroneous evaluation of commands which could in fact be valid JS code.

For example the following should output 'received' and not be evaluated on line 4 as the .help command.

> (_ => {
  const x = { help: 'received' };
  return x
  .help ;
})()

Since the .break command is only used to get out of a bind in multiline input, and CTL-C does the exact same thing, it has been removed.

Refs: https://github.com/nodejs/node/pull/20625

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
• [x] tests and/or benchmarks are included
• [x] documentation is changed or added
• [x] commit message follows commit guidelines

Closing as outdated

This commit modifies the JS language implementation so that it will look for a user provided package.json in the same directory as the function file. If one exists, it uses this instead of the generated one.

NB: This does mean that if a user has provided function dependency information in the function file in the form:

// kfn:dependency primal 0.2.3

These dependencies will be superceded by what is found in package.json

This commit includes the changes in https://github.com/openshift-cloud-functions/kfn/pull/25

It appears to me that perhaps this omits the prompting of name and path entirely, right?

@lkingland I may be misreading your comment, so disregard if so (or correct me). The prompt occurs on line 121.

derivedName, derivedPath := deriveNameAndAbsolutePathFromPath(prompt.ForString("Project path", c.initConfig.Path, prompt.WithRequired(true)))

What kinds of characters in in will cause this to fail?

Nit:

// deriveNameAndAbsolutePath returns resolved Function name and absolute path

I wonder if this function could be better named as it no longer really derives the name, but instead just pulls it from the configuration file or returns the passed value.

Nit: the comment is no longer valid

This deriveNameAndAbsolutePathFromPath() function is called in newInitConfig() which is called by newCreateConfig(), so it seems redundant to call it again here. The values for c.initConfig.Path and c.initConfig.Name should already be set, shouldn't they?

This commit adds nodemon and an npm run debug command to the Node.js templates to support debugging on localhost.

Uses the Cobra "Long" configuration for each command to provide more descriptive text.

Example:

faas help create                                                                                                      1.3m  Mon 21 Sep 2020 09:55:40 PM EDT
Create a new Function, including initialization of local files and deployment

Creates a new Function project at 'path'. If 'path' does not exist, it is
created. The function name is the name of the leaf directory at path. After
creating the project, a container image is created and is deployed. This
command wraps 'init', 'build' and 'deploy' all up into one command.

The runtime, trigger, image name, image repository, and namespace may all be
specified as flags on the command line, and will subsequently be the default
values when an image is built or a Function is deployed. If the image name and
image repository are both unspecified, the user will be prompted for a
repository name, and the image name can be inferred from that plus the function
name. The function name, namespace, image name and repository name are all
persisted in the project configuration file .faas.yaml.

Usage:
  faas create <name> [options] [flags]

Flags:
  -c, --confirm             Prompt to confirm all configuration options - $FAAS_CONFIRM
  -h, --help                help for create
  -i, --image string        Optional full image name, in form [registry]/[namespace]/[name]:[tag] for example quay.io/myrepo/project.name:latest (overrides --repository) - $FAAS_IMAGE
  -n, --namespace string    Override namespace into which the Function is deployed (on supported platforms).  Default is to use currently active underlying platform setting - $FAAS_NAMESPACE
  -p, --path string         Path to the new project directory - $FAAS_PATH (default "/home/lanceball/src/go/src/github.com/boson-project/faas")
  -r, --repository string   Repository for built images, ex 'docker.io/myuser' or just 'myuser'.  Optional if --image provided. - $FAAS_REPOSITORY
  -l, --runtime string      Function runtime language/framework. - $FAAS_RUNTIME (default "go")
      --templates string    Extensible templates path. - $FAAS_TEMPLATES (default "/home/lanceball/.config/faas/templates")
  -t, --trigger string      Function trigger (ex: 'http','events') - $FAAS_TRIGGER (default "http")

Global Flags:
      --config string   config file path (default "~/.faas/config")
  -v, --verbose         print verbose logs

This commit adds nodemon and an npm run debug command to the Node.js templates to support debugging on localhost.

The hardcoded, initial value for the configuration path was set to .faas/config. But configPath() immediately sets this to the correct value of ~/.config. Both the create and init commands use configPath() to search for additional templates, if they exist, and were each doing filepath.Join(configPath(), "faas", "templates"). This commit also changes configPath() so that it is ~/.config/faas and does so in a cross platform friendly way. If the $HOME directory cannot be determined, the config is assumed to be at ./.config/faas.

I've added some documentation for the CLI commands here and called out some odd behavior with the options in a couple of places. I wrote this as I was trying to sort out how I felt about https://github.com/boson-project/faas/pull/125 and https://github.com/boson-project/faas/issues/126 and thought that it would be a good document to use when trying to rationalize any usability changes. For the most part, I have changed my mind about #125 and #126. I'm still on the fence about faas delete, but as I wrote in the doc here, there are valid reasons to have the commands that we do and I'll just eat crow. :bird:

Also - note that for all commands except init and create, I have documented them as they are today. For the init and create commands, I documented them as intended for https://github.com/boson-project/faas/pull/127.

This commit removes the --path -p flag for the build, delete, deploy, describe, run and update commands. The init and create commands have been left alone for now, pending the outcome of https://github.com/boson-project/faas/issues/123. The list command doesn't need to know a path, because it's about seeing all deployed Functions.

Adds a faas.LoadFunction(path string) function to load an existing Function project from disk and return an error if one does not already exist.

Note: I realize this might be controversial. Speak up if you disagree with this proposal!

Edit: The idea here is to enforce the notion that all commands (other than init and create) are run from within a Function project directory where the configuration file .faas.yaml defines the context. Some of the comments from @matejvasek identified areas where functionality has been reduced - e.g. you can't describe or delete a function by name. I think we should actually consider removing these, and possibly even consider removing faas deploy and faas update.

BREAKING CHANGE

Landing this. @boson-project/contributors, let's be sure to keep it updated as the commands change.

OK, so for Quarkus there would be jvm and native. For Node.js debug and production. What about Golang?

The cobra package, magically appends "[flags]" to the usage string if a command has flags. By adding "[options]" to the usage string, we end up with help text that looks like this.

  faas init <name> [options] [flags]

This commit fixes that.

What if, instead of configuring builders explicitly, we simply add metadata to the templates. For example:

❯ cat templates/node/http/.builder     147ms  Fri 18 Sep 2020 03:49:45 PM EDT
───────┬──────────────────────────────────────────────────────────────────────
       │ File: templates/node/http/.builder
───────┼──────────────────────────────────────────────────────────────────────
   1   │ quay.io/boson/faas-nodejs-builder
───────┴──────────────────────────────────────────────────────────────────────

The hardcoded, initial value for the configuration path was set to .faas/config. But configPath() immediately sets this to the correct value of ~/.config. Both the create and init commands use configPath() to search for additional templates, if they exist, and were each doing filepath.Join(configPath(), "faas", "templates"). This commit also changes configPath() so that it is ~/.config/faas and does so in a cross platform friendly way. If the $HOME directory cannot be determined, the config is assumed to be at ./.config/faas.