Allow specifying registry configuration in module.cue

[jmgilman]

Is your feature request related to a problem? Please describe.

Having to maintain CUE_REGISTRY can quickly become tedious in projects with a large number of contributors (e.g., open-source). It's possible to embed setting this value in automation, build scripts, command runners, etc. However, these all feel like band-aids for what is otherwise something that should be natively specified in the CUE configuration.

The issue is even more apparent in repositories with multiple modules that may use different registries. Then it becomes a problem of how to set the environment variable. Do we have some custom commands/configuration to set it properly per module? (e.g., something like a .envrc using direnv in each module). Or do we sacrifice locality and set a wide-spanning CUE_REGISTRY in a command runner script outside of the module directories?

No matter how you parse the issue, the solution always seems to be suboptimal, in my opinion.

Describe the solution you'd like

There already exists a "registry file" format (see cue help registryconfig). My initial recommendation is to consider embedding this schema into the module.cue file. To enable backward-compatibility, I recommend against sunsetting CUE_REGISTRY as it still may be useful when there's a desire to override the registry configuration for a specific run.

I don't have a particular suggestion on where to put it in module.cue. I will leave that up to the maintainers.

Describe alternatives you've considered

I described alternatives in the problem statement.

Additional context

We are rapidly expanding the usage of CUE in our projects and have greatly benefited from the introduction of modules. However, as I've gone about writing tools, configuring CI, and helping developers, the inflexibility of the CUE_REGISTRY environment variable has continued to be a painful problem.

[myitcv]

@jmgilman thanks for raising this.

The issue is even more apparent in repositories with multiple modules that may use different registries.

It would be good to understand this setup a bit better. What are the multiple registries you are multiplexing between here?

Incidentally, if sharing details privately is preferred (recognising the internal architecture might be exposed by such an answer), I'd be very happy to jump onto a call.

My initial recommendation is to consider embedding this schema into the module.cue file.

My initial reaction here is that it doesn't feel right for this kind of environment information to be published as part of module artefact, but I will suspend that thought until I understand the setup a bit better!

We are rapidly expanding the usage of CUE in our projects and have greatly benefited from the introduction of modules.

This is great to hear. Very happy to help understand the problem better, and also work towards a solution that reduces this friction.