SPM installation

[abeintopalo]

Hi,

First, I'd like to thank you @krzysztofzablocki for your awesome work. Sourcery is a very useful tool. :)

I'm using Sourcery via SPM. Just updated to 0.6.0 version.
I've built it with swift build an it built just fine.

My Package.swift file:

import PackageDescription

let package = Package(
    name: "Package",
    dependencies: [
        .Package(url: "https://github.com/krzysztofzablocki/Sourcery.git", Version(0,6,0)),
    ]
)

I use the tool in an Xcode build step:

"${SRCROOT}/Package/.build/debug/sourcery" --sources "${SRCROOT}/MyProject" --templates "${SRCROOT}/Package/.build/checkouts/Sourcery.git-2310539879416764236/Templates" --output "${SRCROOT}/generated/code"

When I build my project I get the following error:

Error Domain=NSCocoaErrorDomain Code=260 "The folder “SwiftTemplateRuntime” doesn’t exist." UserInfo={NSFilePath=<MyPath>/Package/.build/debug/SwiftTemplateRuntime, NSUserStringVariant=(
    Folder
), NSUnderlyingError=0x7fba9a43e580 {Error Domain=NSOSStatusErrorDomain Code=-43 "fnfErr: File not found"}}
Command /bin/sh failed with exit code 4

Any clue what could be the problem?

Any help is appreciated.

Br,
Attila

[ilyapuchka]

Hi @abeintopalo !
Thanks for reporting that. I'm afraid SPM setup was never working with Swift templates. We recently added one template example (Decorator.swifttemplate), so that's why it is now failing. If you point it to your own templates (not swift ofc), it will work.

I think it will be fixed with #240 that requires the same changes as this issue (extracting runtime files into a module)

[abeintopalo]

Hi @ilyapuchka,

Thanks for the help. By creating my own template folder and removing Decorator.swifttemplate did the trick.

It is a good workaround for now.

[ilyapuchka]

@krzysztofzablocki Not sure if there is good solution for that. The problem is that SPM does not build the tool the same way as Xcode does, but for swift templates to work we expect (in #240, or as described here we expect files to be copied but it only happens in Xcode build phase) that we have a framework with all models in the bundle, which requires Cocoa app. What we can do as a workaround is to include this framework into releases and ask users to copy it manually to SPM build folder (or add an CLI argument to provide this path) and then when tool runs check if it was built with SPM (it sets flag for that) and instead of copying from bundle copy framework from that path...
The same problem we have with js templates, as EJS script is also loaded from bundle. I quickly checked this approach with js templates, it works, but its too much hustle to setup... Ideally it should be just one command.

Do you think it worths the effort? I even not sure if SPM is a proper way to distribute utilities, to be honest, as it might try to link modules to the actual user target, what is unneeded. Is there a way to define development dependencies in SPM?

[krzysztofzablocki]

the only reason we added SPM really was for the homebrew distribution as far as I can remember, if we can distribute with brew without SPM then I'd be ok dropping it, @vknabel knows SPM way better than I do so might have some insights

[abeintopalo]

Yeah, I agree that brew distribution would be more ideal for a tool cause that's kinda the standard on MacOS. E.g. I use Swiftformat and that one is distributed via brew.

[vknabel]

@ilyapuchka @krzysztofzablocki As you have enough problems dropping the SPM support seems reasonable. Especially since some features don't seem to work.

Sourcery should not be declared directly inside the manifest file, because it doesn't provide any frameworks and it would link all of its dependencies into the targets (Sourcery itself as an executable won't be linked).

If you want to support linux in the long term, then there is no way around the SPM.

It just makes it easier to install Sourcery manually and is more flexible than Homebrew can ever be (which is fine in most cases).
It's up to you wether you want to continue SPM support or drop it (temporarily or permanently).

Whatever you will decide, I will keep the Homebrew formula working.

[krzysztofzablocki]

Would be good to keep it given the Linux compability as it opens Sourcery benefits to Swift on Server which I imagine will be big market soon.

@ilyapuchka would it be possible if the SPM build would auto download / copy missing files from the Release zip ? on first run

[ilyapuchka]

Am I missing something or Sourcery is currently not usable on Linux because of NSObject and all other stuff?...

Regarding additional build step I was also thinking about that, but I don't think SPM supports that currently. If we provide a setup script which will do that it would be better, but again it seems kind of fragile setup, because if user does clean build with spm it might erase those files. Or we need to link to SPM checkout folder in the code, but it also might change because I think it includes some kind of hash or commit sha or something in folder name...

[krzysztofzablocki]

Yeah it wouldn't work on Linux right now, there are some ports of ObjC runtime for linux but not sure if anything feasible to use as I didn't have time to evaluate.

@ilyapuchka I didn't mean it as build step, more as in the runtime verification, if files are missing we'd download them inside Sourcery or do you think thats a bad idea?

The main thing that matters to me is homebrew, if we can have homebrew working without SPM support, thats fine to drop for now

[ilyapuchka]

hm, we might try that, but still feels like overkill, it should all be bundled with binary. I think we should think in the direction of plugin system and make js and swift templates "pluggable", maybe this way it will work better. And stencil will be default.

[vknabel]

@krzysztofzablocki @ilyapuchka Most parts of Foundation are available on Linux. It is likely that Sourcery currently doesn't work on Linux yet. But it should be quite easy.

Since Swift 3.1 (I guess) checkouts include a hash or so in their path.

Regarding "pluggable" Swift Templates: what about bundling Marathon and providing a Framework for those Scripts? On the other hand it would require an intermediate format for all Sourcery data.

[krzysztofzablocki]

@ilyapuchka Lets keep it simple for now, if homebrew works without SPM lets just remove official support for it for now.

We are already ahead of my original plans for 1.0, so I'm thinking what we should do is to finalize some of our tasks around better error reporting etc, get to 1.0 release with stable app, and then we can work on architecture changes and adding support for Linux to 1.5 / 2.0 release, does that sound reasonable?

I'll be after my work deadline in 2 weeks and will finally have more free time so we can plan & coordinate some changes for post 1.0 phase

[krzysztofzablocki]

Related https://twitter.com/merowing_/status/857242016291459072 as I just realized Apple added Sourcery to their test suite today, let's keep SPM but just support Stencil only templates for it and fail with that info when someone tries to use other ones. Should be straightforward to add and allows us to execute the plan as described

[ilyapuchka]

we can simply ignore any other templates when built from SPM, logging a warning maybe?

[krzysztofzablocki]

I'd fail the generation if any unsupported templates are found, same argumentation as we discussed in the #233

[natechan]

It looks like the sourcery installed from homebrew does not support swifttemplate files. Based on the above discussion, it sounds like that is not intended. Is that correct?

$ sourcery --version
0.11.2

warning: Skipping template /path/to/some.swifttemplate. Swift templates are not supported when using Sourcery built with Swift Package Manager yet. Pl
ease use only Stencil or EJS templates. See https://github.com/krzysztofzablocki/Sourcery/issues/244 for details.

[ilyapuchka]

It is intended