twostraws / Ignite

A static site generator for Swift developers.
MIT License
1.71k stars 94 forks source link

PublishingContext.copyResources() fails when Ignite included as a package #135

Open vdhamer opened 2 weeks ago

vdhamer commented 2 weeks ago
            for asset in assets {
                try FileManager.default.copyItem(
                    at: assetsDirectory.appending(path: asset.lastPathComponent),
                    to: buildDirectory.appending(path: asset.lastPathComponent)
                )
            }

This is copying from the wrong directory (when Ignite is not a stand-alone project).

This in turn is due to the following 'constructor' in URL.selectDirectiries(from:)

            return SourceBuildDirectories(source: buildDirectoryURL,
                                          build: buildDirectoryURL)

where (when Ignite is not a stand-alone project) the source: and build: directories should be different. They clearly are identical.

The bug does not affect projects where Ignite runs stand-alone and the code detects a Package.swift file. I will submit a PR (I apparently introduced this bug myself in #126, but see also discussion in #127).

vdhamer commented 2 weeks ago

False alarm!

I had forgotten that the code of a regular app cannot access its own source directories at runtime. So any images, .md files, handmade HTML files, etc need to be copied over to the sandbox at /Users/<user>/Library/Container/<myApp>/Data by the website developer: a MacOS app doesn't have the privileges to do that unless you disable sandboxing.

I will still submit a PR now with a cleanup with extra comments to URL-SelectDirectories.swift to document this. The README.md file probably still needs updating, but that awaits a direction on #127 by @twostraws. I am also fine with a draft README section on the directory usage in both cases, followed by me/someone adapting the code to match the spec and chosen terminology.