Proposal - Move the Xcode project rules into a separate repository

luispadron commented 1 year ago

rules_ios currently supports two different ways for generating and building Bazel projects in Xcode.

These rules add a fair amount of complexity and their tests have been a source of confusion in several PRs. I.e. updating the fixtures, bzlmod support, requiring use of Intel/Rosetta to ensure fixtures are the same as CI.

Should we instead separate the repositories such that rules_ios contains the Apple bundling rules and rules_ios_xcodeproj contains the legacy & xchammer Xcode rules?

IMO this fixes a few issues:

Users who don't use rules_ios for Xcode project generation no longer need to understand or maintain these rules.
Maintainers/contributors to the Xcode rules now have a tested repository where they can dictate the versions used for rules_ios & it's dependencies.
Maintainers/contributors to rules_ios who do not use or have worked on the Xcode rules can better focus on improving the existing iOS rules.

luispadron commented 10 months ago

@thiagohmcruz @jerrymarino Thoughts?

thiagohmcruz commented 10 months ago

I can see the benefits of splitting things up this way, one concern is how would CI work? IMO It's very useful to know right away (in a PR) that a change to the rules broke the Xcode project generator so I assume one (potentially minor?) downside is that the dependency inversion here implies that rules_ios_xcodeproj would have to manage its dependency on rules_ios SHAs and vet changes independently correct (similar to what rules_xcodeproj does today)?

Re XCHammer I added most things here when I was experimenting with it. If anything XCHammer/xcbuildkit is blocking things we should simply delete the code since (1) we were the only ones using it as an experimental thing that was not supposed to break any main flow and (2) we can always blame and bring back if anyone wants to continue the XCHammer work.

luispadron commented 10 months ago

I can see the benefits of splitting things up this way, one concern is how would CI work?

The goal here would be so that folks in this repo do not have to worry about it. It should be something the users of the legacy generator care about. If newer rules_iOS breaks something for legacy generator the maintainers of the legacy generator would be responsible for fixing it vs. right now that cost is on everyone.

thiagohmcruz commented 10 months ago

I'm mostly thinking of users of rules_ios that are also relying on the legacy generator (we are the main consumers I think but I don't think if we're the only ones?).

If the generator breaks the cost is on everyone today because the legacy generator is part of the repo and the intent is to provide a set of rules and an Xcode generator that work together. But, I understand that the proposal here is exactly to break that dependency.

To us it would be less of a problem soon since we're migrating to rules_xcodeproj but my concern is about "legacy generator maintainers" not having CI vetting that the legacy generator continues to work until someone bumps rules_ios there or someone reports an issue (ideally we would catch these things earlier).

I'm not against the proposal, I just want us all to understand the trade-offs as maintainers and wanted to brain dump what is on my mind.

If we knew how many folks rely on it it would be a lot easier to make a call 😔. I wonder how other OSS repos solve for that without being creepy and collecting data they shouldn't 🤔 (surveys I guess?).

luispadron commented 10 months ago

Yeah it would be useful to understand how many users are using these rules first for sure.

jerrymarino commented 10 months ago

The built in generator is what we currently use, ( AFAIK other folks using rules_ios ) and it does make it easier having it in tree for us. If we move off of it, it might be an argument in favor of removing it: when folks use either xchammer or rules_xcodeproj to generate projects. At the EOD these rules are pretty interchangeable to generate the pbxproj.

These rules add a fair amount of complexity and their tests have been a source of confusion in several PRs. I.e. updating the fixtures, bzlmod support, requiring use of Intel/Rosetta to ensure fixtures are the same as CI.

Is there an issue with running ./tests/xcodeproj-tests.sh --update ? We use the script quite often to bump the fixtures and have seen large adoption of rules_ios with this generator. I also wonder how we can improve the situation by moving to another repo

bazel-ios / rules_ios

Proposal - Move the Xcode project rules into a separate repository #756