Road to 1.0.0

[cgrindel]

Goals

1. Remove need for Swift index JSON file.
2. Move Gazelle plugin to its own repository.
3. Create release 1.0.0.

Tasks

• Process SPM Package.swift and Package.resolved in the repository rule.
  • Stop reading the index file in the repository rules.
  • Be sure to return the correct repository info so that mod tidy will update the MODULE.bazel file with the correct use_repos declaration.
  • Remove all of the index files in the examples.
  • Remove all of the swift_deps START and swift_deps END comments.
  • Update bzlmod/workspace to use from_package().
• Update the Gazelle plugin to not use the Swift index JSON file.
• Update //:swift_update_pkgs to just run SPM commands without using Go. Be sure to use the Swift toolchain, not the Swift installed on the system. (Possibly, create a new macro that creates the commands for running Swift package commands.) For now, I removed swift_update_packages. If people would like a way to update Swift packages using Bazel, we will do it as a separate feature.
• Fix examples
  • grpc_package_example
  • symlink_example
  • ios_sim
• Move Gazelle plugin to its own repository.
  • Create a repository for the Gazelle plugin. chore: migrate files from rules_swift_package_manager and set up CI swift_gazelle_plugin#1
  • Publish to BCR. [email protected] bazelbuild/bazel-central-registry#4059
  • Remove Gazelle plugin from rules_swift_package_manager. chore: use swift_gazelle_plugin for examples and other integration tests #1538
• C/C++ language standards should be set per-target #1079
• Ensure that the documentation for the bzlmod extensions are generated. #1168
• Upgrade to Bazel 8 #1563
• Create release 1.0.0.

[cgrindel]

Notes regarding Gazelle plugin

• No more update_repos.
• rules_swift_package_manager will define a repository called swift_direct_deps_info. It will contain the list of direct dependencies for the workspace (i.e., those defined in the Package.swift).
• The plugin
  • It will use repo.FindExternalRepo to find the swift_direct_deps_info and read the information written there. (NOTE: We could just read the list of repo names by parsing the MODULE.bazel. However, I think that we want to support non-bzlmod a bit longer.)
  • It will then read the pkg_info.json file that lives at the root of every Swift package repository.
  • This will populate the DependencyIndex.

See below for new plan.

[brentleyjones]

What do we need DependencyIndex for anymore? Aren't product names deterministic now?

[cgrindel]

What do we need DependencyIndex for anymore? Aren't product names deterministic now?

The Gazelle plugin needs to resolve module names to Bazel labels.

[brentleyjones]

Ahh, so that won't be in this repo in the end? Got it.

[cgrindel]

For anyone following along at home, this branch has the examples working if you run bazel test //..., no index file required. 🙂 I started updating the Gazelle plugin to work properly in this new world. Here is the basic plan:

• Provide a swift_deps_info repository rule that generates a JSON file with the module/product/package information that is needed to resolve modules to Bazel targets.
• Update the Gazelle plugin to read this file and load it as the DependencyIndex.
• I anticipate keeping the existing API for the DependencyIndex. So, I hope that there won't be any other major changes to the resolve and generate portions of the Gazelle plugin.
• Remove the update repos portion of the Gazelle plugin.

[brentleyjones]

Can we add #1079 to this?

[cgrindel]

Can we add #1079 to this?

Done.

[cgrindel]

Just a quick update regarding the v1 release. I have been working on #1079. I have a draft PR (#1217) with everything working except the rules_xcodeproj no-sandbox build. Unfortunately, that fails with duplicate definitions. I see and mostly understand why this is happening. Unfortunately, I am struggling to prevent the duplicate module map files causing the errors.

I put together #1266 which attempts to prevent objc_library from creating its own module map file by specifying the one that rules_swift_package_manager creates. Unfortunately, this causes an error:

In file included from external/rules_swift_package_manager~~swift_deps~swiftpkg_firebase_ios_sdk/FirebaseInstallations/Source/Library/FIRInstallations.m:25:
external/rules_swift_package_manager~~swift_deps~swiftpkg_firebase_ios_sdk/FirebaseCore/Extension/FirebaseCoreInternal.h:15:1: error: use of '@import' when modules are disabled
@import FirebaseCore;
^
1 error generated.

Looking through the actual command-line, I do not see the -fmodules flag. I thought that this was added by setting enable_modules = True.

If anyone has any thoughts or suggestions, please send them my way.

[cgrindel]

The cgrindel/swift_gazelle_plugin has been submitted to the BCR.

[cgrindel]

@brentleyjones @jpsim @luispadron I think we are all set to create release 1.0.0. Is there anything else that we need to consider before pulling the trigger?

[luispadron]

Only thing I can think of is if fixing #892 would introduce any breaking changes, maybe we'd want to wait for that? But I think changes should be contained to the upstream rules

[cgrindel]

@luispadron TBH, I have not been following that issue very closely. It sounds like the gist is Xcode allows building different packages with different flags, while Bazel's rules, by default, want to build everything with the same set of flags. I can see imagine that rules_swift_package_manager would need to generate build files for the packages differently, but I don't think there would be an API/usage change. Let me know if I am missing something.

[AttilaTheFun]

@cgrindel I think we should not cut 1.0 without this and Xcode 16 / Swift 6 support:
#1423

There are popular SPM packages like grpc-swift using Swift 6 features that will fail with RSPM.

Additionally, can we break the dependencies on gazelle, swift_gazelle_plugin and rules_go for the module, even if they're used in some examples?

[cgrindel]

Swift 6 support was never part of the release 1.0.0 plan. Adding support should not be a breaking change.

With regard to gazelle dependencies in the examples, I have no intention of removing it there. They help with the maintenance of the examples.

With regard to Go deps in rspm, if someone wants to reimplement the Swift deps tool in Swift, that is fine with me. However, I don't anticipate working on it at any time soon. Since it will not be a breaking change for the ruleset, I don't see it as a blocker for release 1.0.0.

[cgrindel]

There are popular SPM packages like grpc-swift using Swift 6 features that will fail with RSPM.

@AttilaTheFun What is needed to support Swift 6?

[AttilaTheFun]

@cgrindel There are several SwiftSettings introduced in Swift 6 for enabling various language features like private imports, strict concurrency checks, requiring existential any etc. RSPM will fail on packages that use them.

Re: go deps, it's fine for them to be dev dependencies but IMHO it would be a surprise to me as a developer if a repository rule for swift packages added a dependency on rules_go for no apparent reason.

With gazelle it makes sense because it's a go tool, but for people just using RSPM they shouldn't need it.

[luispadron]

Re: go deps, it's fine for them to be dev dependencies but IMHO it would be a surprise to me as a developer if a repository rule for swift packages added a dependency on rules_go for no apparent reason.

It shouldn't unless you're using the swift_deps_info stuff

[luispadron]

But to Chucks point, i dont think adding Swift 6 support changes anything about the public API for rules_swift_package_manager and so its not really a blocker for 1.0.0

[AttilaTheFun]

@luispadron is it smart enough to not load the go dependencies if the module depends on them but the specific rule does not? At the very least it could cause versioning issues.

@cgrindel not sure about your feelings regarding AI tools but I have found Claude to be very good at translating things between languages. I'd be happy to try feeding the deps tool into it and asking it to translate it to Swift + fixing it up.

[cgrindel]

Re: go deps, it's fine for them to be dev dependencies but IMHO it would be a surprise to me as a developer if a repository rule for swift packages added a dependency on rules_go for no apparent reason.

Some details from @fmeum:

What you are seeing isn't the actual Go SDKs, it's just the small repo with their toolchain targets
That repo is fetched eagerly with any dep on rules_go, but it's just a single file

tl;dr It is not downloading the Go toolchain implementation unless you enable the swift deps info functionality.

[cgrindel]

@cgrindel not sure about your feelings regarding AI tools but I have found Claude to be very good at translating things between languages. I'd be happy to try feeding the deps tool into it and asking it to translate it to Swift + fixing it up.

I am happy to review. However, I still do not believe that this is required for release 1.0.0. Again, swapping out the underlying tool should not be a breaking change.

Keep in mind, you are only enabling this functionality, if you want to use the Swift gazelle plugin. Using gazelle will bring down the Go toolchain among other things.

[cgrindel]

With gazelle it makes sense because it's a go tool, but for people just using RSPM they shouldn't need it.

Much of the work that went into release 1.0.0 was mitigating the Go dependencies. We have it squirreled away such that you don't take the hit unless you want that functionality.

[AttilaTheFun]

Ok that seems reasonable though I would still like to help break the non-dev go dependencies at some point. People might see them on registry.bazel.build, not know how or when they're used, and be confused.

[AttilaTheFun]

Regarding the SwiftSettings, I understand it's not a breaking change, but I still think announcing the 1.0 release while not supporting an increasing number of packages is strange.

[luispadron]

That's fair, what's left for swift 6 support?

[AttilaTheFun]

@luispadron I have a pr for the swift settings but it's blocked on the CI running Xcode 15. @cgrindel said there were some errors when he tried to upgrade but we haven't had time to debug them yet.

[cgrindel]

@AttilaTheFun So, we need to drop support for Xcode 15?

[AttilaTheFun]

@cgrindel I don't know if we have to drop support for Xcode 15, but some packages like grpc-swift now require Swift 6. Specifically I believe it was my new example exercising these Swift 6 features that was failing in CI

[cgrindel]

@AttilaTheFun Do you think that merging #1423 is sufficient to declare victory for release 1.0.0?

[AttilaTheFun]

@cgrindel yeah I think so -- I just rebased it. It would be nice to mark rules_go as a dev_dependency but I suppose that's not a hard blocker. Not sure if removing it later would be considered a breaking change @brentleyjones ?

[cgrindel]

It would be nice to mark rules_go as a dev_dependency but I suppose that's not a hard blocker.

It is not a dev dependency, at this time. Removing a dep should never be a breaking change.

[brentleyjones]

Yeah, it wouldn't be a breaking change. It's fine as is for 1.0.

I would like to land #1516, but I don't have time right now to add the example for it.

[cgrindel]

Let's create a release candidate (e.g., 1.0.0-rc1). It will signal our intention to create a 1.0.0 release. It may encourage folks to try it out before we declare victory.