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. swift_gazelle_plugin@0.1.0 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.