Watchman is good for performance but we want the basic installation process to be more straightforward. We can use https://github.com/paulmillr/chokidar, which is performant and well maintained (it's used by VSCode among others).

(supersedes #90)

I'm bumping into some issues with our module spec API. I'm trying to balance a few things and figure out what degree of control to give plugins, and I worry a bit about our current YAML layout.

For a bit of context, I'd first off (and definitely) like to make one important change: parseModule should no longer return a class, but rather a validatable object with something like the following interface (which can be readily validated on the framework side):

{
  config?: ModuleConfig    // this allows the handler to optionally modify the configuration, e.g. set some default values (which are then re-evaluated and validated by the framework)
  services: ServiceConfig[]    // a list of services defined in the module
  tests: TestConfig[]    // specify which tests the module includes
}

We'd then define all of ModuleConfig, ServiceConfig and TestConfig as non-extendable interfaces, potentially each with a generic metadata object property that plugins can use at will.

This would mean we could completely do away with generics on Module, Service etc. across our framework code and leave it to plugins to keep the metadata properties type-safe, as well as make it more safe overall from poor plugin implementations.

Another implication is that module specs can technically have whatever structure or semantics, and plugins just need to convert the spec into the above structure. For example, using the term services may not be immediately intuitive in some contexts, and in some contexts a single service (in our framework parlance) may be implicit in the module definition.

Which leads to the concern: To what degree should module configurations be strictly defined at the framework level, and how do we ensure separation between framework-native parameters and pluggable ones?

Another example (in addition to the semantics of what "service" means), is how tests are defined at the module level. We currently have a tests key in the native module spec but it includes a command key that really only makes sense for container and generic modules. So we'll need plugins to be able to specify whatever instructions for the test execution that make sense for that plugin. Do we then evaluate the test key for every module but allow plugins to extend that definition? Or do we omit it entirely from the native spec and rather try and push for conventions in how tests are defined (i.e. urging for them to have a similar layout as our internal TestConfig interface)? Same goes for the build spec.

Yet another issue is how we maintain a backward-compatible separation of native keys in module specs and plugin-specified keys. Example - say we decide today that name, description, and type are framework-native fields that we validate, but not test. Some plugins then implement test as part of their spec, aaaaand then we change our minds and want test to be in our native spec. We're gonna need to be smart about this. At the very least we need to make the fixed fields part of an API version on our side, and make sure that we catch plugins using conflicting fields properly (and before using the values).

So, I'm trying to balance with a simple and clean API. It's always possible to go full-on XML and massively overcomplicate to deal with stuff like this, but I'd like to arrive at a good compromise where we deal smoothly with these concerns and keep the DX slick.

What do y'all think?

When running garden inside tmux/screen there's this weird issue with a few of the background colors.

Left is a normal terminal, right is under tmux.

Output looks like this:

➜  hello-world (master) g status
providers:
  local-kubernetes:
    configured: true
    detail:
      namespaceReady: true
      metadataNamespaceReady: true
      systemReady: true
services:
  undefined:
    endpoints:
      - protocol: http
        hostname: hello-function.hello-world.local.app.garden
        port: 32000
        url: 'http://hello-function.hello-world.local.app.garden:32000'
    runningReplicas: 1
    detail:
      resourceVersion: 2323881
      lastMessage: CREATE Ingress garden--hello--hello-world/hello-function
    state: ready
    lastMessage: ''

Notice the undefined key under the services key.

@edvald After bumping garden version number from 0.0.1 to 0.1.2, the package-lock.json was not updated, resulting in the lock file to be always changed after running npm install.

(Note: I'm pretty sure I caused this bug myself, but I may still assign to someone else)

Currently when a task errors, the spinner for its log entry still runs, and dependant tasks still execute. The expected behaviour would be for an error state to be set on the log entry, and dropping dependant tasks.

It would be cleaner to have all the examples (and there should be many more over time) to a separate repo. We'd need to stop using the hello-world as part of our tests, but we want to do that anyway.

Currently we do both (e.g. garden run module and garden env configure). We should change this to be consistent across the board. Verb before noun seems more natural, and also more commonplace, so I think we should go for that.

While working on #192, I came across a couple of bugs:

1. garden build -w doesn't rebuild modules when sources change (though it does properly perform a restart when garden.yml files are affected).
2. If module-b depends on module-a, changes made to module-a while a deploy or build task for module-b is in progress don't trigger a redeploy/rebuild as they should.

Since these aren't regressions (I encountered the same behaviours on master, using the old watchman-based logic), I decided to address these in a separate PR.

After running gulp, gulp watch or npm run watch, kill -9 <PID> is needed to shut down the watch process.

The command spits out an endless stream of log entries, so the fancy logger makes no sense and flickers a lot. I wasn't sure how best to do it, so handing this off to @eysi09 .)

Or even environmentDefaults? That would be more verbose but quite clear. Either way I think globals isn't super clear. We talked about it at the time, but I didn't follow up on it. What do you all think makes sense?

I'd like to discuss and lay out some options and a proposed design for "hot reload", a feature that would allow rapid reload of containers (and by extension any other modules that are transparently run as containers).

The problem
Currently our re-deployments always require a re-build and full restart of pods, which can take a long time compared to the built-in live reload that many servers offer in development mode. This is one of the pain-points often associated with containers and can often slow down development substantially.

People apply a number of different "hacks" to get around this, such as running development containers that mount host volumes (only works on local machine), Telepresence which is interesting but non-trivial for the end-user as well, and probably some other options involving port proxy-ing etc that I can't think of myself.

We'd like to make this as smooth as possible in our framework, so I'd like to lay out a couple of ideas that I've been mulling over.

Option 1: Automate Telepresence
I mentioned above that using Telepresence is non-trivial, but I figure many of the steps involved could be abstracted and automated away in the framework. The way it would work (in basic terms) is that we'd derive the appropriate parameters for Telepresence (such as port numbers) automatically from the container configuration and you'd get a command like garden telepresence my-service. This would deploy a proxy container in place of the my-service container in the cluster, and start a telepresence shell locally on your machine.

This would actually be a rather neat feature, but it does mean you'll need to run the command for each service you're working on, so it's not at all transparent. We'd also need to make sure other runs of garden deploy/dev/test don't interfere with the proxy (basically abort deploying unless you use --force, something like that).

Option 2: Sync code to remote volume
Much the same way we use rsync to sync to our build staging directory, we could use it to sync to a container running rsync, on top of a shared volume, which we then mount in the corresponding service container(s). This has the benefit of having the container run in its actual environment, and that we could transparently sync code for any number of services.

This would have to be "opt-in" at the service level. Not all modules would work with this out of the box, and you'd need to configure some specifics. I imagine you'd want something like the following:

module:
  type: container
  # ...
  services:
    - name: my-service
      # ...
      hot-reload:
        command: [npm, run, dev]  # the command to run instead of the normal start command
        sync:  # where to sync the module source to
          target: "/app"

Some open questions:

1. Do we deploy a module using the hot-reload mechanism by default or not?
2. Do we configure the hot-reload default by environment perhaps?
3. How do we keep track of the "version" that's running when syncing code?
4. What implications does this have in terms of dependencies?

You may note that options 1 and 2 are not mutually exclusive, but we should think about what our preferred path is and what we think would be most valuable. And of course - will there be dragons in our path towards either of these?

Discuss :)

When Docker is downloading images (e.g. when garden environment configure is initially run), maybe the log output should indicate something like Downloading image....

I ran garden environment configure inside the hello-world example project today, and the command seemed to hang (to my silly self, at least, since I hadn't touched this functionality before). The log output was in this state for ~20+ seconds:

Configuring undefined environment ⚙

✔ kubernetes         → Environment configured

... and then the Done! line suddenly appeared below. I'd CTRL-C'ed it a couple of times before that.

Would be cool to add a download progress bar if possible, not sure what Docker's API allows around that.

Currently we get a less-than-helpful BackOff - back-off restarting failed container when a container doesn't successfully start when deploying.

A reasonable workaround is to run the troubled service with garden run service <service-name> to see what it spits out, but it would be better if we'd get the service log output when this particular error happens.

This probably relates to some refactoring I did, but I'm assigning to you @eysi09 since you worked on this a while back :P

The new logger looks really promising, but could use a few fixes and improvements. We should log them here. The one's I've found so far:

1. Emoji disappear when calling .update(). We should probably use the same formatting function for both new and updated lines to avoid discrepancies.
2. The first section width is inconsistent between lines that use emojis/symbols and those that don't.
3. It might be good to add a .close() method to entries, that changes the state but doesn't set a visible success/warn/error state, if only for efficiency.
4. It would be super nice to be able to nest entries, something like

    const entry = ctx.log.info({ msg: "Deploying services" })
    const nestedA = entry.nest.verbose({ msg: "Deploying service A" })
    const nestedB = entry.nest.verbose({ msg: "Deploying service B" })
    nestedA.done()
    nestedB.done()
    entry.done()

5. We could make the rendering flicker less with a few adjustments - basic one being to simply move the cursor whenever a character hasn't changed, instead of replacing lines.
6. I think I'd prefer to have separate methods for updating an entry and appending to it, rather than the replace parameter.

I can add more things as I come across them, and might commit a couple of small changes here and there.

I'm not really sure if or how we're gonna do this, but I thought I'd create this issue to centralize the discussion.

The idea is to run garden as a container to avoid the whole headache with the installation process.

One issue raised was that of watching the filesystem. We can (probably) do that with docker run -v (link), which will affect performance though we don't know whether it'll have a negligible impact or not. (Could this help?)

General links about containerizing tools:

• Containerize your developer experience (talk, 13mins)
• Distributing Command Line Tools with Docker (article)
• Docker Basics for Local Development (article)

Not a priority by any means, but it'd be nice to have ctx.log.info("some string") available as a shorthand for ctx.log.info({ msg: "some string" }).

I figure that's clearer than calling the default environment local, and also more suitable as we grow platform support and introduce more remote providers.

I figure it has to do with this: https://stackoverflow.com/questions/9046749/rsync-not-synchronizing-htaccess-file

This can cause a variety of build issues, but should be easily fixed. Just need to be careful with the rsync syntax (slashes and such).

Some of our features require recent versions of the docker client and server, as well as Kubernetes. We should check for these at startup to avoid non-descriptive errors at runtime.

It's fairly standard to have proper packages for Debian/Ubuntu, and since we have a fair number of system dependencies I think it'd be a good idea to set up, similar to our Homebrew package for OSX.

It'd be great for it to be configured to automatically set up when releasing, not sure how easy that is though?

It'd be nice to have a quick screencap showing basic usage on the README, helps to explain at a glance what Garden is and does.

It can be confusing if a flag doesn't work, like when you mistype something.

@eysi09

Now FancyLogger catches strings/buffers from other streams and passes them to the RootLogNode. This can cause flickering when printing user input from stdin. Current workaround is to simply stop the logger, have the normal process take over and then resume below on the next log call which results in the logger loosing access to the content already printed. The reason we can't just pause the FancyLogger is that the logUpdate library is unaware of the new content and therefore uses the wrong prevLineCount.

A better solution would be to:

1. Pause FancyLogger every time it intercepts other streams.
2. Print the content using the stream it originated from.
3. Silently add content to the log graph.
4. Implement own logUpdate function which recognises that the graph has changed and updates the prevLineCount accordingly.
5. Resume FancyLogger on next log call.

Supporting Garden projects that span multiple repositories will be a critical feature for many users.

To support that properly, we need to be able to do the following:

1. Reference repositories via git URLs, in the project configuration and/or as sources in module configs.
2. Automatically clone those repos and keep them updated.
3. Locally link a repo to a local clone, so the user can work on multiple repos without circling through the remote repo.

Each of these has some inherent complexities and needs careful design and implementation.

1 - Referencing external sources

We can imagine a few different ways to link external sources (i.e. repos) to a project.
One is to allow a list of sources to be specified in the project config, which will all be pulled in when scanning modules, and then treated as part of the project tree. It could look something like this:

project:
  name: my-project
  # ...
  sources:
  - name: other-repo
    location: git://github.com/my/repo#master
  # ...

We'd then pull each of the referenced repos (unfortunately having to poll for updates changes every time) and then scan for garden.yml files in each of the clones, much like we do currently in the project directory.

Another way could be to add something like an external or sources top-level key to the garden.yml file, which would have a similar format as the above sources key. A benefit of that would be that you wouldn't have to have all the external references in the top-level project config (and they could even cascade across multiple repos), but otherwise it would work functionally the same.

And a third option would be to have an optional source key in module configs, so you'd essentially define the garden.yml for a module in the main project repo, and then just refer to a repo for its source code.

The above aren't actually mutually exclusive, but I'd prefer to pick a single canonical way to do this, at least to start. I'd personally lean towards having a top-level sources key in the garden.yml file.

2 - Cloning and syncing linked repos

Cloning the referenced repos should be fairly straightforward. I guess the only question might be where we clone them to. I think something like .garden/sources/<source name> would make sense.

Keeping the clone in sync is slightly more tricky, particularly when auto-reloading, but also not super complicated. We'd probably need to settle for basic polling for changes, possibly with a configurable poll rate. You might also want to disable automatic updates, if we provide a command to manually fetch latest changes from remote (e.g. garden update-sources)

3 - Link local working copies

Of course you'll want to be able to work on linked repos without having to push changes to the remote all the time. I figure we could add a command to do that locally (since you don't want to hard-code a reference to a local directory in the garden.yml config). Something like:

garden link-source name-of-source ../path/to/local/clone

This "link" would then be stored in your local config and when present the framework will simply look to the local path for the linked sources. This would mean that the user is then responsible for having their local working copy up to date, on the correct branch etc. (because we can't reliably take care of that, in case the working copy is modified/dirty etc.). And we'd of course need a corresponding unlink command.

I imagine it could get a little thorny for users to separately commit changes in multiple repos etc. but then again they likely already have that problem...

I think that mostly covers what needs to happen. Am I missing something?

Currently, only builds, deploys and tests (depending on the command) are run when module sources change. If a garden.yml file is modified, the changes aren't reflected in the process.

Reloading modules should not be too difficult if we specifically catch changes to a module's garden.yml file. We would basically need to trigger a reload of the module (which is possible currently in the Garden class), and stop+restart the processModules method (otherwise we could run into a bunch of inconsistencies).

Handling the project garden.yml might be slightly trickier, but should be achievable. We'd need to refactor the Garden class slightly to allow it to be reset, and we'd need to stop and restart processModules as well.

The alternative would be to just restart the whole process, but that would be kinda lumpy if you're making rapid changes to configs.

In any case we'd also need to elegantly handle errors in the garden.yml file, and not just crash the process.

The command errors out with something like

Error from server (NotFound): deployments.extensions "hello-function" not found
Error from server (NotFound): deployments.extensions "hello-container" not found

The expected behavior would be to ignore missing services, and ideally to retry fetching the logs until they are deployed.

To quote @eysi09 from #55:

Something like:

project:
  name: hello-world
  environments: ...
modules:
  - name: module-a
     dir: /path/to/module-a
     description: Module A description
     type: container
  
  - name: module-b
     dir: /path/to/module-b
     description: Module B description
     type: container

I think this will make sense especially when we allow referencing other git repos, which we'll need to do soon.

Currently when build dependencies that are not explicitly being watched are modified, we don't trigger execution. For example, when I run garden deploy module-a -w and module-b is a build dependency, nothing happens when we modify module-b. Should be fairly easy to fix.

src/watch.ts:computeAutoReloadDependants() currently only deals with module build dependencies. It should be extended to include the modules of service dependencies. Might need to consider #107 along the way (not exactly sure if it applies but I suspect it does).

It would be super nice to have a homebrew package, and to automate the release process along with the npm release. Especially since we do have peer dependencies like git and rsync, that we can't bundle, and we're likely to add more of those if anything.

Currently you can only run from the root directory of a project. We should add a step when starting up to walk up the directory tree from the current working directory and find the closest garden.yml that has a project key.

The logic for this should probably be in the Garden.factory() method, since it will involve parsing garden.yml files.

From #155:

I'm not sure if it's possible to get our lovely banner image to display when running garden dev, which I think only works on iTerm anyway, but in any case the welcome message could be improved when it doesn't work.

When running garden env configure in the hello-world example, the buildModule method of the ContainerModuleHandler class attempts to build local-gcf-container using the relative build dir path as opposed to /garden/static/local-gcf-container.

Throws the following error:

ChildProcessError: Command failed: docker build -t local-gcf-container:0000000000 /Users
/eysi/code/garden-io/garden/examples/hello-world/.garden/build/local-gcf-container
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat
/Users/eysi/code/garden-io/garden/examples/hello-world/.garden/build/local-gcf-container
/Dockerfile: no such file or directory
`docker build -t local-gcf-container:0000000000
/Users/eysi/code/garden-io/garden/examples/hello-world/.garden/build/local-gcf-container
` (exited with error code 1)
    at callback
(/Users/eysi/code/garden-io/garden/node_modules/child-process-promise/lib/index.js:33:27
)
    at ChildProcess.exithandler (child_process.js:282:5)
    at emitTwo (events.js:126:13)
    at ChildProcess.emit (events.js:214:7)
    at maybeClose (internal/child_process.js:925:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)

Having the hard dependency on rsync will be a problem on Windows, and we want Garden to be easy to set up in any case.

I haven't find a well-maintained that directly mimics rsync, but we should be able to conjure something in pure JS and leverage the watcher functionality to copy files as they change.

Parsing the error log is a little difficult as it is currently (JSON per line). I wonder if we could do something like output YAML instead, and prefix each line with a timestamp for clarity? Either that or provide a command that makes it easy to read.

I also noticed that we're just stringifying exceptions, which often omits a bunch of detail. For example, we include a detail property on GardenError instances, which includes helpful information for debugging. Maybe we could handle those specially, even when we print out the error in the CLI.

When running garden with the -log option, garden fails with the below error, but it works when using --loglevel

node ~/devel/node/garden/dist/src/bin/garden.js status -log verbose

USAGE

  garden status [options]

Global options
  -h, --help        Show help
                    [boolean]
....

  -log, --loglevel  Set logger level.
                    [enum] [default: info] [error, warn, info, verbose, debug, silly]


  -o, --output      Output command result in specified format (note: disables progress
                    logging).
                    [enum] [json, yaml]

Value "" is invalid for argument o or output. Choices are: json, yaml

The implementation is over-complicated and brittle. It should be rewritten to not rely on local host paths.

One option is to simply build a container for each function. Not optimal performance/RAM wise, but most straightforward in implementation.

Another would be a slightly more elaborate way, by creating a meta-module that copies sources from each GCF function via build dependencies, and deploys all of them together in a container. The downside being that all functions need to be restarted when updating any of them, but in turn much more efficient in terms of memory usage (not least because the GCF emulator is a bit heavy).

It bothers me a little that we have one type of file called garden-project.yml and then garden.yml files in module directories. Both the aesthetics of it, and for a practical reason, which is that a project will be able to reference other repos. So when you’re in a repository that contains a single module, there is no garden-project.yml and we’ll have a weird usability issue (what happens when you run garden in a module repo root?).

My proposal is this: We merge the two spec files into one garden.yml, and add top level project and module keys (and possibly a plural modules or external-modules key, to facilitate adding multiple references to other repos).

Example

Project root:

project:
  name: hello-world
  environments:
    local:
      providers:
        docker:
          type: kubernetes
          context: docker-for-desktop
        gcf:
          type: local-google-cloud-functions
    dev:
      providers:
        docker:
          type: google-app-engine
        gcf:
          type: google-cloud-functions
          default-project: garden-hello-world
  variables:
    my-variable: hello-variable

Module:

module:
  description: Hello world container service
  type: container
  services:
    hello-container:
      command: [npm, start]
      endpoints:
        - paths: [/hello]
          containerPort: 8080
      healthCheck:
        httpGet:
          path: /_ah/health
          port: 8080
      dependencies:
        - hello-function
  build:
    dependencies:
      - hello-npm-package
  test:
    unit:
      command: [npm, test]
    integ:
      command: [npm, run, integ]
      dependencies:
        - hello-function

I feel like this'd feel a bit cleaner, plus it opens up a bit of flexibility in our configuration down the road imo. Thoughts?

This would basically allow plugins to "throw" errors in a type-safe and easily handled manner, instead of throwing arbitrary exceptions. This'll be much cleaner, especially for 3rd party plugins.

Just a thought. I for one always get confused as to which is more verbose, "verbose" or "debug". And I can imagine us wanting to set multiple levels at some point.

For example, in kubectl you can set --v=8 to dump a lot of logs. We could for example alias the named levels to the numeric levels (0=error, 1=warning, 2=info etc.), and perhaps make l an alias for --loglevel to make it more concise.

It's a bit of a stability/security concern to let plugins return potentially non-compliant objects that are used in the framework. The parseModule() handler should instead return a module config that can be validated, potentially with a free-form key that can be passed back to plugin action handlers.

Plugins would then be responsible for upgrading basic Module objects to more specific subclasses, or we could perhaps add some convenience feature for doing that automatically before passing to action handlers.

I found out the hard way that lerna doesn't really support having a package in the repo root. I figure we'll also have multiple packages in the repo at some point, so I'm thinking we should move all the stuff we end up packaging and releasing as garden-cli to a garden-cli subdirectory.

We'd keep some stuff like bin, docs and some config stuff in the root. Figure it'd also make the top-level directory a bit cleaner, it's a bit crowded at this point.

Any objections...?

I'm working on the ability for users to set configuration parameters locally (per project/repository) and I’m wondering about how we might handle the semantics of configuration, internally and (perhaps most importantly) in the CLI.

For context, we may eventually end up having several different types of configuration:

1. Custom project parameters that are intended to be populated locally by each user of a project. This could for example apply to user-specific keys, flags that individual users can set while developing/debugging etc. and can in general be used to supply secrets (although we will also need to provide a specific secrets storage in the hosted platform).
2. Custom project parameters that are stored remotely and shared across the team and all environments. For example authentication keys for 3rd party services, that are not specific to individual developers or environments.
3. Custom project parameters that are stored remotely but are specific to a single development environment (which may or may not be shared across the team). For example authentication keys for 3rd party services that need to be different for individual environments (e.g. a specific key for an analytics service in the shared staging environment).
4. Built-in local per-project configuration parameters, such as authentication info for the hosted platform, CLI preferences (e.g. defaulting to output JSON or YAML). The names/schemas of these parameters could be specified by plugins.
5. Built-in project parameters that are stored remotely and shared across the team. Could apply to anything that should be kept secret but would otherwise belong in the garden-project.yml file, for example custom SSL certificates for the ingress endpoint.
6. Built-in global parameters for the garden framework. This could again apply to authentication info for the hosted platform, CLI preferences (e.g. defaulting to output JSON or YAML) etc. I'm unsure if we want something like that, or if we should stick to just per-project/repo configuration.

Or to frame this another way, configuration parameters may be:

• Built-in at the framework level
• Defined by plugins and integrations/apps
• Custom (i.e. implicitly defined in the project config files via template strings)

And may have the following scopes:

• Account/Team (we may introduce a distinction between those at some point, for enterprise accounts with multiple teams)
• Project
• Environment
• User/local (should those have a distinction, i.e. remote user parameters and local user parameters?)

So that's all in all quite a few things to consider (and I may be missing something as well?). We won't implement all of the above in the short term, but what I'm grappling with now is how we would like to see this look in our CLI and config files, such that it is easy to understand and elegant, since it would be annoying to change substantially later.

To try and decompose this a bit, I'm going to raise some questions that I've bumped into, discuss each of those, and then try and converge on something that looks pretty good.

Do we want to have a semantic distinction between remotely hosted custom configuration variables and secrets?
Seeing as secrets are basically configuration variables except with a clear indication that they're, well, secret (meaning encrypted remotely etc.) I see no reason why you would want non-secret variables on the remote platform, I'm leaning towards having no distinction there, but rather considering just the two "dimensions" listed above.

When referencing these parameters, should we explicitly reference them with a scope (e.g. user.some.key and team.some.key) or implicitly collapse values based on scope (so just write some.key and use the value defined in the most granular scope)? Should we allow both?
There's no cut and dry correct answer here. The former has the benefit of being simpler to implement, as well as being more explicit so it's less likely to cause confusion as to where something is configured. The latter in turn allows more flexible overrides at different levels of scope (e.g. having default values at the account level, but allowing users to override). Allowing both would raise some edge case issues, like having to disallow user, team etc. as top level names for parameters, and my feeling is I'd rather have it explicitly work one way or the other. That is unless we have another "scope" that called something like all, combined, collapsed, coalesced or something like that (ideas welcome), so you can explicitly choose to use the most granularly defined value.

How should we separate between built-in parameters, plugin parameters and custom/project parameters?
I think each of the above should have its own namespace at same same level, but a follow-on question could be whether other template resolvers (e.g. the one for getting environment variables in the user's environment) are also at the same level or whether these should fall under a top-level config. prefix. I'm leaning towards the latter, for consistency and clarity, so parameter values could be accessed with ${config.<namespace>.<key>}.
As for the namespace names, the built-in namespace can simply be called garden. Plugins could have their own namespace, which will simply be the name of the plugin. I'm not 100% sure what to call the custom namespace. custom doesn't sound quite right to me, but maybe it's fine + I can't think of a clear alternative. Another way could be to not have a namespace for custom parameters, and instead use some symbol prefix for built-in/plugin parameters, e.g. ${[email protected]}. Looks a bit weird though, because it doesn't look like a normal identifier, no matter which prefix we use (except _, which doesn't work because it makes it look like a private property).

Should there be a distinction between user config values and local config values?
This one is at least fairly easy. We can just start with local and if we see a need for user configuration that is stored remotely per user, we can add it later under a user scope.

Should there be a special indication of namespace and/or scope in the CLI when setting configuration values (e.g. Heroku-style garden config:local set bla=ble as opposed to garden config set local.bla ble)?
This may depend a bit on how we answer the above questions on namespaces/scope, but I'd lean towards "nah" and say keep it simple. If we make this distinction, we'd kinda need it to look similar in template strings for consistency, and I can't think of a solid way to do that or a good reason to.

... Anyway, by now you likely understand why I'm struggling a bit with this. 😖

I'll keep thinking on this and put in some suggestions on how this might look, but thoughts would be appreciated.

This is because we make the assumption in our current Module.getVersion() code that modules are in a project git tree. We need to add more ways to specify versions and/or automatically retrieve the version of the plugin and use that instead. Or I suppose we could hash the contents of the plugin directory, but that feels like it would be flimsy. Ideas welcome.

#99 slows the CLI down somewhat due to repeated resolution of template strings and preparation of runtime contexts. Some simple caching should be applied to avoid this and make the CLI more snappy.

... or cause inconsistent/valid builds.

This could be resolved using locks at the file-system level, by staging builds differently or even using a daemon process to make sure a single task-graph runs for the user.

Other concurrent/conflicting tasks, such as tests and deployments, could also fail or cause issues (depending on how the providers are implemented) but conflicting build tasks are most likely to have a negative impact.

There are quite a few places where we emit rather opaque error messages. I'll gather some examples here as I come across them. We should btw also in general format error messages in a nicer+clearer way, instead of just spitting out an object, which may involve some different shape of our error objects.

• Error when failing to call docker CLI commands doesn't indicate why
• Error when Kubernetes provider can't be reached should say that specifically
• When key in template string is not found, it would be good to list which top-level keys are available (because it may not be obvious what's available in the context of each string).