More options around managing enabled resources

Describe the Feature You Want

I've been working on setting up my company's stack to run via Tilt for local development and some things I've come across that could be useful:

A way to determine which resources are enabled

I realize the fact that you can enable or disable resources from the UI makes this tricky, but I would love a way to get a list of resources that are enabled, including dependent services.

set_enabled_resources and clear_enabled_resources functioning during tiltfile reloads

It would useful if on a Tiltfile reload if the values passed into set_enabled_resources caused a change in what was actually enabled, and if clear_enabled_resources was called it would actually disable all resources.

Current Behavior

You can determine which resources were specified via deploy args, but you can't know what's actually enabled due to dependencies.

set_enabled_resources and clear_enabled_resources don't appear to change anything when run during a Tiltfile reload.

Why Do You Want This?

First, I'm trying to track and respond to conditional dependencies. For example, let's say I have a service called berry with a berry-api resource for the backend, and berry-fe for the front end. I also have a service airplane that also has a backend and front end, named airplane-api and airplane-fe. Due to how these services work together, I have to run a flying-grocery configuration job to put some stuff into their respective databases if they're both running, but if only one is running I don't want to do that (and can't, because they both have their own database instance running and if airplane-api isn't running then there's no airplane-db for the config job to talk to.

Also, each front end has a dependency on its respective backend via resource_deps (berry-fe depends on berry-api, airplane-fe depends on airplane-api).

So the end result is that a developer could run tilt specifying berry-fe and airplane-fe to run, and that means implicitly that berry-api and airplane-api would run. And in that case I would like my configuration job to run. So I would like the ability to check if berry-api and airplane-api are enabled either directly or indirectly, rather than needing to "know" all the dependencies and express them a second time in my checks (aka I check if berry-api or berry-fe is specified and if airplane-api or airplane-fe is specified).

Second (and these are ultimately related) is that I'm trying to allow configuring what runs and what doesn't via a configuration file. Because of the amount of configuration we're putting into this, we read settings from a local yaml file that lives alongside the Tiltfile which allows for much more complex configuration than can be done with command line arguments or the corresponding tilt_config.json.

I've been able to write my Tiltfile such that I have a configuration file with a list of resources to run, and I can properly parse that and pass it options into set_enabled_resources such that what I expect to be enabled is enabled. But if I modify my configuration file to enable another resource, when Tilt detects that change and re-executes the Tiltfile, it doesn't enable that new resource.

It is possible somewhat mimic this behavior by conditionally including Tiltfiles instead of enabling services (for the berry service we have a Tiltfile just for berry and call include in the main Tiltfile to load it). That would require splitting up each logical resource into its own Tiltfile (there would now be berry-api and berry-fe Tiltfiles instead of a single berry Tiltfile) and that would lose out on a lot of the automatic resource dependency tracking already built in to Tilt. If I were to go down this path, then I would have to manually manage dependencies such that if someone only specifies berry-fe to run that I would not only have to load the berry-fe Tiltfile, but the berry-api Tiltfile as well. That also means that my airplane-grocery-config resource job, which depends on berry-db and airplane-db will throw a warning if I haven't loaded both the airplane-api and berry-api Tiltfiles, because Tilt won't know what those resources are. It's not a fatal error, but if there are warnings there, people are going to ask about them and I'd like my developers to not have to understand too much about the inner workings of Tilt to be productive locally.

Additional context I believe the changes in #6767 are also required for some of this to actually function. For example if I dynamically don't load a Tiltfile when I change the config file, those resources will be removed and any down-policy annotations will be ignored.

Also, when services are specified via the command line, and you run tilt args with new values, the services that are running get changed to what I specify while still preserving the existing Tiltfile process, so I think a lot of the capability I'm looking for exists in the guts of Tilt, it's just not all being exposed in a sufficient way to take advantage of it.