Some more FAQs possibly

[luispadron]

This is sweet! Just tested it out on the CLI tool were building at Cash and was able to successfully use it to replace our dependency on swift-argument-parser (which rules_spm was having version conflict issues with previously).

Couple of immediate Qs:

• Is it possible to not have the Package.swift and other files in the root of the repo? Possibly in a per-package way?
  • One possible use case is to have a App/Package.swift and Tool/Package.swift for example.
  • I tried to change the path in the gazelle command and it generates the lock and swift_deps.bzl correctly in a different path outside the root but it looks like the swift_deps_index.json file is always output to root directory.
  • Additionally, the labels generated for the WORKSPACE assume the swift_deps.bzl file is at //:
• Im a bit confused about when update_build_files is needed, I didn't have to use this at all to get building. The README suggests this should be run every time the sources change, is that true?

[luispadron]

Im a bit confused about when update_build_files is needed, I didn't have to use this at all to get building. The README suggests this should be run every time the sources change, is that true?

Ah! https://github.com/cgrindel/swift_bazel/blob/main/docs/faq.md#can-i-just-manage-my-external-swift-packages-and-not-generate-bazel-build-files-for-my-project

[cgrindel]

With regard to putting the files in a different location, I created #136 to track the enhancement. This should be fairly straightforward.

On the topic of having multiple Package.swift files, you could do this. However, there are some issues that you will need to address. If you have multiple Package.swift files and they reference a common external package (directly or transitively), you have two issues:

1. The processing of each Package.swift will generate a duplicate external repository entry for the common package.
2. The duplicate external repository declaration could resolve to different versions for the same package.

As a rule-of-thumb, you want one set of external dependencies for your Bazel workspace. Is there anything that would prevent you from having a single Package.swift file for your workspace?

[luispadron]

Thanks for all the info and the issue for tracking that feature!

I figured we'd run into dependency resolution issues if we use two packages and that's not really a use-case we need, was more concerned with putting the swift_bazel files somewhere outside the root since introducing a Package.swift in the root might be confusing to our engineers since we don't support SPM as a build tool (just for fetching deps)

[cgrindel]

@luispadron Once #146 merges, you will be able to move the Swift dependency files to a sub-package. I updated the vapor_example to demonstrate this.

[luispadron]

Thank you! Excited to get swift_bazel into our repo now