merging multiple instances of same package

[hansbogert]

Is there a way to get a single instance after having done a ./... for a single package?
Because we are in a transitioning from an intricate directory hierarchy with yamls (in the domain of Kubernetes), we'd like to have a single instance over the following directory hierarchy:

root/
- addons
  - application-x
    - some.yaml
  - application-y
    - some.yaml

We cue import all the yaml under a single package:

$ cue import -p foo -fl name ./...

That does mean all the package is shattered over multiple subdirectories:

.
└── addons
    ├── application-x
    │   ├── something.cue
    │   └── something.yaml
    └── application-y
        ├── something.cue
        └── something.yaml

However doing an eval shows us that we are dealing with multiple instances signalled byu the // --- (if i understand correctly)
In order to have policies which act on multiple applications we need to reference them in a cue file in root/, however this seems problematic, take a simple toy policy in root/:

$ cat ./policy.cue
package foo

#allSameIPs: x.ip & y.ip

This results in the following:

cue eval -pfoo   ./...
#allSameIPs: reference "x" not found:
    ./policy.cue:4:3
#allSameIPs: reference "y" not found:
    ./policy.cue:5:3

Probably because ./... does a eval on ./ first . However, explicitly adding both subdirs does not work as well:

$ cue eval -pfoo   ./addons/application-y ./addons/application-x
#allSameIPs: reference "x" not found:
    ./policy.cue:4:3

I understand that you sometimes want to test instances of packages separately, i.e., a single directory and all its direct cue file therein belonging to a single package and ./... seems to do so by iterating over instances.
However, sometimes it's really beneficial to be able to check all cue files recursively in a subdirectory and act on the config as if it is one instance. Is there a way to do that?
Of course I could do some bash-fuu and copy all cue files to the root dir, but that becomes pretty messy imo.

[the-nurk]

sounds like this is a job for #3911