Skip to content

update the resolved file format#3717

Merged
tomerd merged 1 commit into
swiftlang:mainfrom
tomerd:refactor/pin-file-format
Sep 8, 2021
Merged

update the resolved file format#3717
tomerd merged 1 commit into
swiftlang:mainfrom
tomerd:refactor/pin-file-format

Conversation

@tomerd

@tomerd tomerd commented Sep 3, 2021

Copy link
Copy Markdown
Contributor

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 tomerd force-pushed the refactor/pin-file-format branch from 11d48a6 to b12ab5f Compare September 3, 2021 23:59
@tomerd

tomerd commented Sep 4, 2021

Copy link
Copy Markdown
Contributor Author

@swift-ci please smoke test

@tomerd

tomerd commented Sep 4, 2021

Copy link
Copy Markdown
Contributor Author

looks like some ci infra issue failed the linux PR check

@swift-ci please smoke test linux

@abertelrud

Copy link
Copy Markdown
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

tomerd commented Sep 7, 2021

Copy link
Copy Markdown
Contributor Author

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
Copy Markdown
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

tomerd commented Sep 8, 2021

Copy link
Copy Markdown
Contributor Author
❯ 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