I prefer alphabetic ordering, though I don't insist on it. I usually use cmd+shift+O to get where I need anyway.
This can already be achieved with VSCode using a couple of extensions. Might be worth switching to that if that's what you need. Or opening a feedback on Xcode to ask for the ability.
In terms of ordering files and folders, I generally nest directories and files deeply in a way that makes sense to me of the project. E.g. /Models/API/Requests/FormData/CreateUser.swift. And as @Avi
says I rarely search for files in the explorer it's more the quick open, build errors or failing tests
I guess it’s a valuable suggestion for the Xcode team, and you can get it through Feedback Assistant or Apple Developer Forums.
SwiftPM itself should avoid platform-specific functionality in most cases, and this one is even worse. IDE should be adapted for the toolchain itself, instead of the inverse.
1 Like
I'd actually say the opposite, mostly. SPM should embrace platform differences, as long as it can express those difference using public features. Apple is already doing this with their Swift Playgrounds extension of SPM to add the iOSApplication target type. However, they're doing so in a way that forks SPM, which is extremely unfortunate. Support for these targets should be part of the open source project. SPM cannot survive Apple's bifurcation (trifurcation, with Xcode's integration).
3 Likes
I agree with this, to a certain extend -- it makes sense for both paradigms to exist simultaneously, depending on the use case.
For example, I think it's unfortunate that schemes are the only way to configure certain common settings such as environment variables for a test. This kind of bifurcation is inherently not scalable to a world where a package wants to support many (non-Apple) platforms.
In my mind, things like iOSApplication are different, though, since they're an extension for a specific type of package that can only be built with certain tools. This seems similar to how I can make a package that requires UIKit which by definition won't build using other tools than Xcode. SwiftPM just happens to be the underlying technology for configuring the project here and I think, if anything, we should be moving more to a model where vendor-specific functionality can live outside the main project in a well-defined way.
1 Like
What you describe should be a feature of SPM. It should be possible to create new target types which are built using external and separate build tools. SPM's support in this area should increase, not diminish. It should be possible for me to create a package that requires UIKit or a particular platform without special handling. It would be best if the integrations that power iOSApplication were generally available so we could create FlutterApplication or GTKApplication, or DotNetApplication. Otherwise Apple is just bifurcating SPM to no real benefit.
IMO, it's not healthy for open source projects to work the way you describe. I know that's how Apple treats all of their developer tools (clang, like Swift, is built differently by Apple and so is missing features the public clang has, like OpenMP support) but it's never been good for the community.
3 Likes
Yep, I agree. That's what I meant when I said "a model where vendor-specific functionality can live outside the main project in a well-defined way" if that wasn't clear.
Sorry, you said they were different, which I though meant different from your earlier agreement. What I meant is that there should only be one SPM. There shouldn't be SPM, Apple SPM, Xcode SPM, and Swift Playgrounds SPM. They should all be able to open each others manifests and handle the same targets, barring the availability of particular tools (iOSApplication obviously can't work without Apple's tools, but SPM should be able to tell you that, and I shouldn't need an Apple build of SPM to support it). Are you more talking about being able to offer new target types as plugins from outside of SPM itself? I guess I agree, though we lose a lot of value if Apple's plugins remain closed source. But I guess it wouldn't be too bad as long as SPM (all versions) can handle missing target types gracefully. Would still kind of suck if public SPM contributors weren't able to test their changes against all uses, or if my plugins didn't have access to the same tools Apple's do.
1 Like
yes, the likely high level design of supporting additional product and target types would be along the lines of plugins. we would naturally take such proposal through swift evolution where we can debate the details of what it should look like exactly
I think in the fullness of time, there should be ways to test and experiment with an OSS build of SwiftPM better together with Apple tooling, regardless if it is delivered as closed source binaries or not.
2 Likes
Right. I guess my primary concern is being able to use a single definition for all the targets I want without breaking tools which don’t support certain targets. Bit of a moot point at the moment since none of the other SPM apps allow you to use your own manifest.
Is IDEPackageSupportUseBuiltinSCM documented somewhere?
(Based on my searches, this seems to be a switch that some know; but, it's primary source is elusive.)
1 Like