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.

Sign up for GitHub

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

Jump to bottom

Use libSwiftPM instead of custom model types #120

Closed
MaxDesiatov opened this issue Oct 4, 2020 · 2 comments · Fixed by #194
Closed

Use libSwiftPM instead of custom model types #120

MaxDesiatov opened this issue Oct 4, 2020 · 2 comments · Fixed by #194
Assignees
@yonihemi
Labels
refactor No user-visible functionality change

Comments

@MaxDesiatov
Copy link
Collaborator

MaxDesiatov commented Oct 4, 2020 •
edited
Loading

Instead of maintaining our own packaga manifest model types, we should consider using the SwiftPackageManifest package to offload this burden. The package is going to be reused in swift-doc in the future, so this feels safe to rely on.
@MaxDesiatov MaxDesiatov added good first issue Good for newcomers refactor No user-visible functionality change labels Oct 4, 2020
@yonihemi
Copy link
Member

SwiftPackageManifest currently fails on dumps generated with Swift 5.3 due to a change in dump-package output, plus at least 2 features are not supported (exact versioned dependencies, dependencies as packages and not names).
I'm working on some PRs for that, but meanwhile seems our decoding approach in Carton helps us avoid these issues - the more minimal decoding for only the parts we need proves more resilient to JSON changes.

@MaxDesiatov
Copy link
Collaborator Author

MaxDesiatov commented Oct 22, 2020 •
edited
Loading

Another option could be a dependency on SwiftPMDataModel target in SwiftPM itself. They say their API is unstable, but it won't break if we stick to a specific Swift version (5.3 in our case).

Then we also get access to things like PackageGraph, which AFAIU allows us to read Package.resolved. We could then run deep checks on the dependency tree to verify that JavaScriptKit is compatible with the runtime version that carton ships with. Right now we can only fetch JavaScriptKit version from Package.swift, but it's not there if there's no dependency specified on it directly.

@MaxDesiatov MaxDesiatov mentioned this issue Nov 6, 2020
Closed
@MaxDesiatov MaxDesiatov mentioned this issue Nov 23, 2020
Closed
@yonihemi yonihemi changed the title Use SwiftPackageManifest package instead of custom model types Use libSwiftPM instead of custom model types Dec 25, 2020
@yonihemi yonihemi self-assigned this Dec 25, 2020
yonihemi added a commit to yonihemi/carton that referenced this issue Dec 25, 2020
@yonihemi
Use libSwiftPM instead of custom model types swiftwasm#120
a9eed09
@yonihemi yonihemi mentioned this issue Dec 25, 2020
Merged
@MaxDesiatov MaxDesiatov removed the good first issue Good for newcomers label Jan 11, 2021
yonihemi added a commit that referenced this issue Jan 20, 2021
@yonihemi @MaxDesiatov
Use libSwiftPM instead of custom model types (#194)
4ef7b53 
* Use libSwiftPM instead of custom model types #120

* Update SwiftPM dependencies

* Add wrapper to handle discrepancy between encoded and decoded Manifest

* Try to fix 5.2 dependency resolving

* Try to fix 5.2 dependency resolving

Co-authored-by: Max Desiatov <max@desiatov.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@yonihemi yonihemi

Labels
refactor No user-visible functionality change
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Use libSwiftPM instead of custom model types yonihemi/carton
2 participants
@MaxDesiatov @yonihemi