`Marathon run` causes the update of all cached Packages about marathon HOT 2 OPEN

I think I'm seeing a similar issue in my own project right now. It seems to be pulling in and adding all the subdependencies as dependencies.

For example, I was using PathKit, which uses Spectre to do testing. After running a couple of times I start getting complaints about XCTest not being available (which Spectre uses). Spectre has nothing to do with PathKit other than during tests though.

Hoping to investigate this more myself too. I suspect it is related to the way pinned packages work, but can not yet confirm that. Marathon attempts to avoid duplicate dependencies from different scripts, but I wonder if something in either the Swift language or Marathon has changed recently that is causing this.

from marathon.

Okay, I can confirm the problem is consistent with mine and provide some more info now. It's all about what's going on in the cache. I'll try to keep it short and to the point:

• Marathon caches a bunch of data inside of ~/.marathon.
• Marathon creates a "master" at ~/.marathon/Packages/Generated/Package.swift file that it uses as the template for generating the Package.swift file of each respective script which live at locations using this pattern: ~/.marathon/-Users-name-and-path-to-script-slug-script-name/Package.swift
• After updating twice, all dependencies and their children get listed in the Generated/Package.swift which is used as a template.

See evidence below. I used your terminal.swift code in the example for consistency.

~/.marathon/Packages/Generated/Package.swift after initial install of terminal.swift

~/.marathon/...terminal/Package.swift after initial install

~/.marathon/Packages/Generated/Package.swift after marathon update

~/.marathon/...terminal/Package.swift after update/run

If you have multiple scripts with dependencies, their dependencies likely start to intermingle also, and all future compilations fail. It also could increase the compilation time of very basic scripts.

Seems to me that the template Package.swift pattern probably needs revising. I'm currently investigating support for multiple dependencies from the same Package, which has been surfacing this problem too. See #191

from marathon.