Skip to content
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

Merged
merged 1 commit into from
Sep 8, 2021

Conversation

tomerd
Copy link
Contributor

@tomerd tomerd commented Sep 3, 2021

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

@tomerd tomerd added the ready Author believes the PR is ready to be merged & any feedback has been addressed label Sep 3, 2021
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
@tomerd
Copy link
Contributor Author

tomerd commented Sep 4, 2021

@swift-ci please smoke test

@tomerd
Copy link
Contributor Author

tomerd commented Sep 4, 2021

looks like some ci infra issue failed the linux PR check

@swift-ci please smoke test linux

@abertelrud
Copy link
Contributor

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.

@tomerd
Copy link
Contributor Author

tomerd commented Sep 7, 2021

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 Package.resolved version 2 is not valid and ask the user to fix it, which I think is the most we can do. wdyt?

@abertelrud
Copy link
Contributor

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 Package.resolved version 2 is not valid and ask the user to fix it, which I think is the most we can do. wdyt?

Ok, an error makes sense. I thought I saw a precondition which would cause a crash but was mistaken.

@tomerd tomerd merged commit 0419392 into swiftlang:main Sep 8, 2021
@tomerd
Copy link
Contributor Author

tomerd commented Sep 8, 2021

❯ swift package update
error: Package.resolved file is corrupted or malformed; fix or delete the file to continue: unsupported schema version 2

mattt pushed a commit to mattt/swift-package-manager that referenced this pull request Sep 16, 2021
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready Author believes the PR is ready to be merged & any feedback has been addressed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants