Open watt opened 5 months ago
For #924, I am working on #957 that as of right now removes swift_update_package
. I hope to get it to a good place in the next week or so and then socialize the API change with the community. Most of the functionality in swift_update_package
will be obsolete. The question is whether folks like have ability to run swift packages update
via Bazel target.
There will still be a call to swift package resolve
under the hood somewhere, right? I think as long as that's happening, the ability to customize it is my request here, regardless of how that gets exposed.
There will still be a call to swift package resolve under the hood somewhere, right?
It will occur somewhere. With the new design, the ruleset does not need to hook into the swift package resolve
. So, I removed swift_update_package
. It is an open question whether the community likes being able to execute this step via Bazel.
Personally, it feels like we should provide some way to execute this step via Bazel. It helps ensure that the swift package resolve/update
use the same version of Swift as the rest of the build.
Personally, it feels like we should provide some way to execute this step via Bazel. It helps ensure that the swift package resolve/update use the same version of Swift as the rest of the build.
+1, this should be done in Bazel, so that we can also get bazel mod tidy
to run as part of that step.
Related to #1016 , I'd like to be able to pass arguments to
swift package resolve
, namely the ones described in the SwiftPM docs under "Using registry for source control dependencies":I could see this being an argument to the
swift_update_packages
rule, along the lines of:Or if it's preferable to not encode that abstraction, being able to pass arbitrary arguments through to the
swift
command would work here too.