Move usage of plugins from dependencies to plugins parameter to align with SE-0303
#3312
Conversation
abertelrud
requested review from
friedbunny,
neonichu and
tomerd
as code owners
abertelrud
changed the title
dependencies to plugins parameter to align with SE-0303dependencies to plugins parameter to align with SE-0303
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
abertelrud
changed the title
dependencies to plugins parameter to align with SE-0303dependencies to plugins parameter to align with SE-0303
Move the usage of plugins from the `dependencies` parameter of targets in the package manifest to instead be in a separate `plugins` parameter. Despite their similarity to dependencies we want users to consider them differently. This also leaves room to grow in the future, when plugin usage might support parameters, etc. We encode them separately in the manifest JSON, but merge them into regular dependencies to avoid duplicated implementation on the SwiftPM side. This can be changed later without affecting clients. For now it would just mean duplicate code. rdar://74663667
abertelrud
force-pushed
the
extension-usage-spelling
branch
from
98eeb00 to
31dba14
Compare
|
@swift-ci please smoke test |
abertelrud
added
the
ready
| successors += pluginUsages.compactMap({ | ||
| switch $0 { | ||
| case .plugin(let name, let package): | ||
| return (package == nil) ? potentialModuleMap[name] : nil |
There was a problem hiding this comment.
should this be case-sensitive or case-insensitive?
There was a problem hiding this comment.
That's a good question — I did the same thing as what's being done earlier for the regular dependencies, so if we make it case-insensitive here, we should change it for regular dependencies too. So that would be a semantic change that I don't think we should make in this PR.
There was a problem hiding this comment.
IMO we should consider such change, but I agree a separate PR makes sense
There was a problem hiding this comment.
Right, making target dependencies case-insensitive seems like a different consideration that should probably be tied to tools version. Regardless, I think that dependencies and plugin usages should be consistent. We can file a tracking JIRA on the case sensitivity.
| return .product(Target.ProductReference(name: name, package: package), conditions: []) | ||
| } | ||
| else { | ||
| guard let target = targets[name] else { return nil } |
There was a problem hiding this comment.
should this be case-sensitive or case-insensitive?
There was a problem hiding this comment.
Same comment as the other one.
Move the usage of plugins from the
dependenciesparameter of targets in the package manifest to instead be in a separatepluginsparameter.Despite their similarity to dependencies we want users to consider them differently. This also leaves room to grow in the future, when plugin usage might support parameters, etc. We encode them separately in the manifest JSON, but merge them into regular dependencies to avoid duplicated implementation on the SwiftPM side. This can be changed later without affecting clients. For now it would just mean duplicate code.
Modifications:
rdar://74663667