How much does this proposal help with version conflicts? Could an example be added to show how I use it to resolve those kinds of conflicts?
Also, is module aliasing for conflicts between versions something that can be handled by SwiftPM automatically?
For example, if both the Utils depended on AnalyticsPackage but pinned to different versions? I imagine for the same build product, no, since linking would fail for duplicate symbols or something like that. But for an Xcode workspace or a root, unifying package where the build products pin the same one dependency at different versions, this could be automatic, right?
We will have to modify the version resolution in SwiftPM to account for aliased modules of different versions; this won't be part of an MVP though, but will be added in the future (future directions in the proposal will be updated to reflect this).
The problem being addressed is certainly significant enough, and I am glad to see that this proposal starts to tackle it. I've read through the proposal twice and followed the reviews.
I can't recall an earlier discussion phase, though, during which potential alternative designs were discussed. I do appreciate that the present solution is a fairly involved one with changes to many projects and want to be pragmatic about the feedback now that we are here. But I do have thoughts on the overall design:
I think the stated motivation is a very persuasive one, and particularly note this line:
it is important to be able to resolve the conflict without making invasive changes to the conflicting packages
Where the solution as currently proposed comes into limitationsârequiring building from source, having runtime impact, etc.âthey all stem from the fact that under the hood module aliasing actually triggers a very invasive change to the conflicting packages, with name mangling altered throughout.
It is not clear to me that there is no less invasive alternative but to do this, and if indeed there isn't one then modules without available source can never be aliased and not just as a temporary limitation of the implementation.
This would be particularly sad since, as the proposal states, nested namespacing or submodules could be a great long-term solution for many pieces of the motivating problem, but retroactive resolution of naming conflicts would still require a feature like module aliasing. However, this feature as currently designed specifically cannot accommodate binary-only modules that (unlike ones built from source) really cannot be altered and must have these naming conflicts dealt with retroactively.
Ideally, packages are able to name modules without using unnecessary prefixes (which could ultimately collide anyway), and trust dependents to alias them at their discretion.
On a related but separate note, Iâd also like to see submodule support in the future. Packages like Swift Collections currently use the unstable @_exported attribute to emulate this for overlays, which is hardly ideal. Once modules can be grouped in that fashion, you can use that for disambiguation as well.
import Collections.OrderedCollections
Running with that possibility for a moment: aliasing Collections.OrderedCollections need not be allowed, but how would you alias Collections without depending on the entirety of it? Would the proposed solution allow that?