Feature Request: Improved target focusing API

[brentleyjones]

The current target focusing API (i.e. xcodeproj.focused_targets and xcodeproj.unfocused_targets) allows for focusing or unfocusing any target you want. They can be annoying to use though if you want to (un)focus a category of targets, such as entire repositories. I say annoying instead of impossible because with a generated BUILD file a query can list out all of the targets in a repository. This has negative performance implications as well, passing around and interacting with large data structures.

I propose that we improve the target focusing API to allow specifying some "more than one target" patterns. The rough idea is to allow more than just labels in the {un,}ocused_targets attributes:

xcodeproj(
    …
    unfocused_targets = [
        "@repo1//some:target",
        unfocused_targets(type = focusing_type.repository, pattern = "repo2"),
        unfocused_targets(type = focusing_type.name.suffix, pattern = "_mocks"),
        unfocused_targets(type = focusing_type.package.suffix, pattern = "_UI"),
        unfocused_targets(type = focusing_type.package.component, pattern = "Tests"),
    ],
    …
)

I'm not sure on the actual spelling of the API (e.g. maybe `unfocused_targets.package.component("Tests") or something instead?), but the idea of being able to specify these matching clarifications is the key thing. With incremental generation mode there is a single location that can do these sorts of matches, making it a lot easier to add this sort of feature.

[erneestoc]

I need to find out how useful this would be; I can't think of cases where I'd use that ^.

For a modular codebase, what I'd use the most is (and don't know if it's possible or not, just an idea):

• focus_target("//My/Target:Label", with_dependencies = UPSTREAM | DOWNSTREAM | ALL | NONE) - to allow me to work on my focused target and related deps without having to scan/add them manually.
• Ability to compile/run my app target without including all of their dependencies in Xcode - in combination with the point above, it would allow me to keep my current dev workflow without all of the stuff I don't need from other parts of the project.

[brentleyjones]

Ability to compile/run my app target without including all of their dependencies in Xcode

That is already possible with the existing target focusing API.

focus_target("//My/Target:Label", with_dependencies = UPSTREAM | DOWNSTREAM | ALL | NONE)

I think this would require something like #1033 to modify the generated xcodeproj target to include the correct concrete {un,}ocused_targets.

I need to find out how useful this would be; I can't think of cases where I'd use that ^.

I'm actually filing this issue for someone else, who I know needs this feature.

[luispadron]

This feature would solve much of the needs we have for generating the BUILD files that define our xcodeproj targets.

If we combined this with some more auto generated schemes (say one that runs all the tests, builds everything, etc) then this would practically replace our custom xcodeproj target generator. At the very least, it would mean we dont have to maintain and run queries before generating a project.

[mattrobmattrob]

This is something that's been implemented by dozens of companies in slightly different ways for the same goal. Unifying the structure with a highly flexible DSL to describe this would be incredibly worthwhile, IMO.

From my past gig, focus_target + Regex/otherwise pattern for targets would have captured the internal implementation. We didn't have un-focusing at the time when I departed.

My only hang up is that likely this would still possibly be a "generated" BUILD file but this gives the flexibility to avoid running queries and so on to find the pattern matches since that could be internal to rules_xcodeproj.

[brentleyjones]

We already create a generated BUILD file, so I'm not concerned about that part. The regex portion would need to do something like that plus query. First we would do the Starlark only stuff, since we would need that infrastructure in place regardless.

[mattrobmattrob]

Sorry, I meant the hang up WRT the "usual" way that folks end up generating a BUILD file outside of rules_xcodeproj. 2 in this pattern:

1. Company CLI that takes some pattern in make project-like script
2. Company script runs the queries/whatever to get the targets for their generated xcodeproj target(s)
3. The internal creation of the BUILD by rules_xcodeproj

I'd bet simplifying 2 (internalizing the target gathering within rules_xcodeproj) yields substantial performance gains for users since it reduces the more-or-less duplicated work of understanding the graph in the company CLI and within rules_xcodeproj.