Just wanted to check if there has been any new development of support for Swift Packages in Swift scripts, latest I've seen is that 10 months ago it was proposed as a GSoC for 2023, but did anyone continue the work from 2021 last year?
I think this is such a great addition to Swift that it would be unfortunate if no more progress would be made.
Personally I’m waiting for some kind of “metadata macro” (like this one). Things got changed significantly since 2021 and it’s mostly clear that if we want it in 2024, it should come as a macro. Currently there’s no such macros that’s targeted for tooling, so that should go into the language first.
(This is just a reminder of another approach that you commented on briefly a while back.)
Perhaps instead of a built-in macro and tricky compiler plugin, a simpler solution would be a new command or swift flag for a driver, to indicate the hosting local package?
When the driver can build the script in a local host/nest package, it solves a lot of workflow and usability questions that would not be addressed with a @Package macro.
As a reminder, here's the ~250-line driver that can (as needed) create, update, build, and run a script by building its "peer" in a local package module with package dependencies (the hosting "nest"):
https://github.com/swift-nest/clutch/blob/main/Sources/clatch/clatch.swift
The more complete clutch driver also handles listing nest peer scripts, finding script peers to edit or emitting them as templates for new scripts, etc. -- all things you end up doing.
For me the best part is that building before run after change is unnoticed/fast because the library is typically pre-built. Also I can check in all the scripts in one package to share with other people.
I prefer having explicit nest/host packages over the implicit local build directories, but that's easily supported. For an example of that (and @Package via comment), see https://github.com/mxcl/swift-sh
I also tend to have scripts in related bundles/nests (Build, Media, Voice, ...). I prefer managing dependencies in one place over changing them in multiple @Package statements in scattered scripts.