Use SPM to build swift templates

[ilyapuchka]

Currently swift templates are compiled using swiftc, which requires to pass it some non-trivial arguments and perform additional step to properly link SourceryRuntime. Instead we can generate package manifest for each template (or a single manifest with executable for each template) and use SPM to build and run them. This will also let us remove all additional steps and code related to caching as SPM should handle it already. It also will allow to use swift templates with SPM Sourcery installation as it will be possible to add SourceryRuntime as dependency for templates, so SPM will build and link it. With swiftc we can only link to framework (though there might be a way to link SPM-build SourceryRuntime, but it will make users to manually build it). This though might increase build times of templates as it will need to build SourceryRuntime at least once, but as it does not change SPM should be able to cache it after first build.

[Liquidsoul]

I've been thinking about doing this for a while. This would potentially open some powerful new features like using library code in Swift templates allowing a nice "plugin" system. One question we must answer is how we will maintain the version of SourceryRuntime contained in the Package.swift Swift templates will use?

[ilyapuchka]

SourceryRuntime version should be the same as version of sourcery tool.

[felix91gr]

Question: can one replace the Swift templates with Stencil ones? Or are there things that are only possible from Swift templates?

[krzysztofzablocki]

Swift ones are more powerful as they are full language, Stencil isn't Turing complete

[ilyapuchka]

The problem with swift templates though is ABI stability, as they currently rely on linking framework shipped with Sourcery, so templates and this framework should be compiled with one version of swift. If you want full power - use EJS, but I think they will work on macOS only, JavaScriptCore does not work on Linux AFAIK

[felix91gr]

so templates and this framework should be compiled with one version of swift.

Ahh, of course. And that's why you'd need to build the SourceryRuntime every time you build a SPM package that uses Swift templates. Right?

[ilyapuchka]

Yes, we copy the framework from Sourcery bundle and link it to template executable. But that makes it impossible to use swift templates with SMP installation because SMP builds do not produce dynamic frameworks.

[ilyapuchka]

Ahh, of course. And that's why you'd need to build the SourceryRuntime every time you build a SPM package that uses Swift templates. Right?

we don't actually use SPM to build swift templates, we use swiftc

[felix91gr]

I see. Yeah, that makes sense.

You'd think that ABI stability is only important for Apple frameworks and such. But no, dynamic frameworks like Sourcery need ABI stability by construction 😄

Stencil isn't Turing complete.

That makes sense. Hmm. I guess it's a bummer, but I could wait and use Stencil for now until ABI stability enables the rest of Sourcery to be used easily outside of Darwin.

[anandabits]

Swift ones are more powerful as they are full language

@krzysztofzablocki I've been working with Swift templates lately and this doesn't appear to be accurate. It looks like Sourcery inlines the template into a function so we aren't able to make use of top-level only language features such as protocols and extensions in a Swift template (please correct me if I have missed something here). I would love to see that limitation eventually.

Right now I'm using include to reference .swift files but that is just a textual include of the source into a function in the main.swift Sourcery creates when compiling a Swift template. Maybe using SPM would make it possible to have real references to .swift files that the compiler sees as files. That is necessary to make the entire language work as expected (including access control, etc).

[krzysztofzablocki]

@anandabits that might be the case, didn't think about those top level only features, I guess you could modify our templating system to support that if you like, we are always happy to accept prs :)

[art-divin]

👋🏻 Hi all,

this issue looks hard enough for me to not understand it. So I might just do this 🦾 Hardest tasks are the most fun ones 🤓 .

I'll update you on this later.

[krzysztofzablocki]

We might already be using spm for this @art-divin

[art-divin]

@krzysztofzablocki huh, go figure 😓 I wonder, if the topic was something about using SPM to create a package and build that, instead of invoking swift build -c release in SwiftTemplate.swift:249 we'd create an SPM package with swift package command, and compile just that, somehow 🤔

[art-divin]

In fact, this is already the case. Closing.