[Pre-pitch] SwiftPM Manifest based on Result Builders

To me, investing time in meeting this decision when there're tons of bugs and existing radars, with a poorly tool integration, it is literally a waste of time and resources to be honest.

2 Likes

+1 for the main approach. Results builder sounds good too. I do think that if folks want to declare all configurations in a config file (json/yaml) then hopefully they can still do this adhoc.

I’m not sure that’s completely fair. Over at the Compile Time Constants pitch, this work could be a step towards improving the performance of SwiftPM:

So maybe with less sandboxes, we might get some of that two-three minutes our Macs spend stuttering playing music, switching Slack channels or browsing web pages while trying resolving 30 or so package dependencies after a changing a branch :grimacing::crossed_fingers:t2:

Bugs > Performance

Doesn't matter that you have the fastest tool if it is unusable because of blocking bugs.
Just my opinion

I'm curious to know what issues you are referring to, and if they're more on SwiftPM itself or its integration with Xcode.

In my experience, all my issues with SwiftPM are in its integration with Xcode, so the unfortunate reality is that even if those get fixed within 24 hours of being reported... they're effectively not fixed for months at a time while we wait for the next version of Xcode to be released.

And in some cases, we have to wait entirely for the new major version of Xcode, leaving bugs existing for an entire year - and then some, as you have to then make sure you're able to build with the new version of Xcode.

1 Like

bundle_resource_accessor, which I believe is generated by Xcode is wrongly generated for example. Boy bear in mind that 95% of SwiftPM relies on Xcode Integration, where is mostly used into, so one problem links to another.

Only two-three minutes? You must have fast internet.

Why does it download the same dependencies time after time even though they haven't changed in months, whenever I change branches.

Why do I have to force quit Xcode if I try to close a project while it's Resolving package graphs?

This is off-topic really but I have terrible internet and SwiftPM's caching is helping me tremendously:

❯ rm -rf .build/
❯ swift build
Fetching https://github.com/crossroadlabs/Regex.git from cache
Fetching https://github.com/mxcl/PromiseKit from cache
Fetching https://github.com/kylef/Commander.git from cache
Fetched https://github.com/crossroadlabs/Regex.git (1.13s)
Fetching https://github.com/kylef/Spectre.git from cache
Fetched https://github.com/kylef/Commander.git (1.14s)
...

I'd like to hug everyone who's helped ship this :)

To make this somewhat on-topic: I don't think arguing this change is without merit because other things are imperfect is fair to the proposal, and I doubt it's helpful to the authors. It's not like this pre-pitch or its eventual implementation would fundamentally prevent those other issues from being addressed.

4 Likes

It seems that Xcode use a private SwiftPM framework, not build upon on the open source swift-package-manager. Their function is the same and share almost the same name but they are different thing. See [Optimus] Simplify resource_bundle_accessor.swift by Kyle-Ye · Pull Request #3824 · apple/swift-package-manager · GitHub and [SR-15550] Loading a resource from a bundle fails due to incorrect bundle path - Swift

That's why I insist on that making progress on spm as a standalone product without taking in mind that it is an apple tool and more importantly, a tool that is widely used in xcode because is our unique IDE is just a fairy tale.
More cross-team and collaboration with the xcode team (for example integrating SPM as a plug-in in Xcode would've been great). But the effort is pushing because it is what it sells more.

3 Likes