## Changes
Move the WorkspaceClient reader and setter from the root package to
`libs/command`.
## Why
This allows us to read the workspace client set in the context in all
CLI packages. This was not possible before because using
`root.WorkspaceClient` would often result in an import cycle.
This would also allow us to standardise reads of the workspace client to
be from the context in bundle commands. Today those are read from the
bundle object tree instead.
This is a natural followup to
https://github.com/databricks/cli/pull/2440.
## Tests
Existing tests and one new unit test.
NO_CHANGELOG=true
## Changes
This PR also starts storing the DBR versions in the context.
Go patch file used:
```
@@
var x expression
@@
-dbr.MockRuntime(x, true)
+dbr.MockRuntime(x, dbr.Environment{IsDbr: true, Version: "15.4"})
@@
var x expression
@@
-dbr.MockRuntime(x, false)
+dbr.MockRuntime(x, dbr.Environment{})
```
ref: https://github.com/uber-go/gopatch
## Why
This localised all DBR version accesses to `libs/dbr`. Relevant comment:
https://github.com/databricks/cli/pull/2432#discussion_r1982878616
## Tests
Exiting tests are modified.
## Summary of changes
This PR introduces three new abstractions:
1. `Resolver`: Resolves which reader and writer to use for a template.
2. `Writer`: Writes a template project to disk. Prompts the user if
necessary.
3. `Reader`: Reads a template specification from disk, built into the
CLI or from GitHub.
Introducing these abstractions helps decouple reading a template from
writing it. When I tried adding telemetry for the `bundle init` command,
I noticed that the code in `cmd/init.go` was getting convoluted and hard
to test. A future change could have accidentally logged PII when a user
initialised a custom template.
Hedging against that risk is important here because we use a generic
untyped `map<string, string>` representation in the backend to log
telemetry for the `databricks bundle init`. Otherwise, we risk
accidentally breaking our compliance with our centralization
requirements.
### Details
After this PR there are two classes of templates that can be
initialized:
1. A `databricks` template: This could be a builtin template or a
template outside the CLI like mlops-stacks, which is still owned and
managed by Databricks. These templates log their telemetry arguments and
template name.
2. A `custom` template: These are templates created by and managed by
the end user. In these templates we do not log the template name and
args. Instead a generic placeholder string of "custom" is logged in our
telemetry system.
NOTE: The functionality of the `databricks bundle init` command remains
the same after this PR. Only the internal abstractions used are changed.
## Tests
New unit tests. Existing golden and unit tests. Also a fair bit of
manual testing.
shreyas-goenka