Gazelle support for runtime usage

[yujunz]

Any plan to bring back gazelle support? It seems removed in 6f86398

[seh]

Not for now, as it's not entirely clear how it should work. We'd have to figure out which rules to use for generated targets, leaving the following questions open for Gazelle to decide:

• Are we depending on a containing CUE module?
  We could look to see whether this Bazel package sits within a CUE module, and assume that we depend on that containment if so.
• Are we defining a CUE instance?
  We'd have to be sitting within a CUE module.
• Which CUE package name should we use?
  We'd have to read the CUE files and group them by their declared package, if any.
• On which other CUE instances should this Bazel target depend?
  We'd have to read the CUE files to get their import declarations, and translate those to Bazel targets.
• Are we looking to use cue export or cue def?

What did you have in mind?

[yujunz]

Agree with all your points

• Are we looking to use cue export or cue def?

Currently I'm using cue_library rule generated by https://github.com/tnarg/rules_cue/tree/master/gazelle/cue. It implements cue def and can be used as basic testing. Unfortunately it doesn't support cue modules and lack of more advanced testing rules for cue export.

Generating rules for cue export is more challenging, since it is often incomplete and sometimes requires injects. So we shall need some annotation to allow gazelle to interpret that.

What did you have in mind?

I'm looking for better test coverage of a complex stack of cue code for app deploy. A quick glance at the layout.

└─ v1/         # work in progress
   ├─ base.cue       # base constraints for all apps deploy
   ├─ *_tool.cue     # cue commands
   ├─ ctx            # shared context (e.g. cluster, region) for app deploy
   ├─ provider       # shared provider for contexts
   └─ app/           # v2 app centric layout deploy
      ├- ...app      # app registry
      └- app-x
         └- region
            ├- ...region  # region instances
            └- region-y
               ├─ region-y.cue  # region-y specific constraints for all envs
               ├─ ...env        # env instances
               └─ env-z
                  └─ env-z.cue  # env-z specific constraints for all app-x variants
                     └─ application: "app-x-v": _  # app-x-v specific constraints

There are over 100 apps and 10 environment, i.e. >1000 cue instances. It's tedious to write test rules one by one and hard to propagate changes. So basically, I want to generate some generic export rules like

app_foo_gen.yaml: stage.cue ../aws.cue ../../../../../base.cue
	cue export --expression 'application.foo.argocd' --force --out yaml --outfile $@

deploy:
	cue export --inject gitRev=$(shell git rev-parse HEAD) --expression application.foo.deploy

cluster:
	cue export --inject gitRev=$(shell git rev-parse HEAD) --expression application.foo.cluster

Do you think gazelle will fit this purpose?

[seh]

Do you think gazelle will fit this purpose?

It would be complicated to implement, requiring reading CUE files and updating BUILD.bazel files in many directories.

If we assume that we're sitting within a CUE module rooted at the Bazel repository's root directory, we'd still have to walk upward through dominating directories to find the ancestor targets for each cue_instance target that we could generate (with multiple per Bazel package), looking for matching CUE package names along the way. That's not even taking account the possibility of having CUE files sit in directories that are not themselves in the root of a Bazel package, but rather in subdirectories within a Bazel package.

[yujunz]

we'd still have to walk upward through dominating directories to find the ancestor targets for each cue_instance target that we could generate (with multiple per Bazel package), looking for matching CUE package names along the way.

Not sure if there's any native interface in cue sdk to extract such information.