-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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.
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
update the resolved file format #3717
Conversation
motivation: resolved file now encodes the package name which is redundant. it also does not include the identity of the package so that needs to be computed frmo the url and could be incorrect in case of "creative" mirroring. it will also pose issues as we transition to registry based dependencies changes: * create V2 of the resolved file format * in new format, encode identity and not name * adjust tests
11d48a6
to
b12ab5f
Compare
@swift-ci please smoke test |
looks like some ci infra issue failed the linux PR check @swift-ci please smoke test linux |
In case a V2 file is written out and then SwiftPM 5.5 tries to open it, I think the result will be an internal error, right? I realize that 5.5 is the way it is already, just wanting to get a sense of how this will be experienced after using SwiftPM 5.6+ and then going back. |
@abertelrud it will give an error message saying that |
Ok, an error makes sense. I thought I saw a precondition which would cause a crash but was mistaken. |
|
motivation: resolved file now encodes the package name which is redundant. it also does not include the identity of the package so that needs to be computed frmo the url and could be incorrect in case of "creative" mirroring. it will also pose issues as we transition to registry based dependencies changes: * create V2 of the resolved file format * in new format, encode identity and not name * adjust tests
motivation: resolved file now encodes the package name which is redundant. it also does not include the identity of the package so that needs to be computed frmo the url and could be incorrect in case of "creative" mirroring. it will also pose issues as we transition to registry based dependencies
changes: