Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Road to 1.0.0 #924

Open
13 of 19 tasks
cgrindel opened this issue Feb 17, 2024 · 8 comments
Open
13 of 19 tasks

Road to 1.0.0 #924

cgrindel opened this issue Feb 17, 2024 · 8 comments
Assignees
@cgrindel
Labels
enhancement New feature or request

Comments

@cgrindel
Copy link
Owner

cgrindel commented Feb 17, 2024 •
edited
Loading

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.
    • Publish to BCR.
    • Remove Gazelle plugin from rules_swift_package_manager.
  • C/C++ language standards should be set per-target #1079
  • Ensure that the documentation for the bzlmod extensions are generated. #1168
  • Create release 1.0.0.
@cgrindel cgrindel added the enhancement New feature or request label Feb 17, 2024
@cgrindel cgrindel self-assigned this Feb 17, 2024
@cgrindel cgrindel mentioned this issue Mar 10, 2024
Merged
@cgrindel
Copy link
Owner Author

cgrindel commented Apr 13, 2024 •
edited
Loading

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
Copy link
Collaborator

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

@cgrindel
Copy link
Owner Author

cgrindel commented Apr 13, 2024 •
edited
Loading

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
Copy link
Collaborator

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

@cgrindel
Copy link
Owner Author

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.

@cgrindel cgrindel mentioned this issue Apr 17, 2024
Open
@cgrindel cgrindel mentioned this issue May 25, 2024
Open
@brentleyjones
Copy link
Collaborator

Can we add #1079 to this?

@cgrindel
Copy link
Owner Author

Can we add #1079 to this?

Done.

cgrindel added a commit that referenced this issue Jun 26, 2024
@cgrindel
feat: no longer need to check in swift_deps_index.json file and oth…
4bf2ffe 
…er big updates (#957)

Lots of big changes in this PR:

- The SPM-related rules no longer depend upon a Swift deps index JSON
file.
- Remove the `from_file` module extension tag class, as the ruleset no
longer needs to read the Swift deps index file.
- Remove the `swift_update_packages` macro as it is no longer required.
- Remove support for `byName` references outside of a Swift package.
This was supported in early SPM versions. It was one of the driving
factors for having to pre-process the Swift dependencies and generate a
Swift deps index file. Removing this support reduces the complexity of
the `rules_swift_package_manager` implementation.
- Remove `update_repos` command from the Gazelle plugin.
- Add `swift_deps_info` repository rule to generate a Swift deps index
JSON file as part of the build, not in the Gazelle plugin. This index
file is used by the Gazelle plugin to resolve Swift module names to
their respective Bazel target.
- Introduce `from_package` module extension tag class telling the
ruleset where the `Package.swift` and `Package.resolved` files for the
workspace live. These are used to identify the Swift package transitive
dependencies for the project.
- Remove the `http_archive_ext_deps` example. The example existed to
demonstrate and test indexing of Swift targets that were downloaded
using `http_archive`. The Gazelle internals no longer provide some of
the information needed for this to work properly with bzlmod enabled.
Given that SPM has been widely adopted and there are some workarounds,
we are removing support for this functionality in the Gazelle plugin
when bzlmod is enabled.
- Add output to the example test runner that demarcates different phases
for the testing.

Related to #924.
@cgrindel
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@cgrindel cgrindel

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@brentleyjones @cgrindel