Support projects with multiple files

[orta]

I'm open to being told a better conceptual way to do this, for context, I'm thinking of https://github.com/danger/danger-swift/issues/8

I have a project that has to have a library target, and ideally some sort of end-user installable script-ish file. Which means multiple swift files in the rep. This script file could probably end up referencing others in the same target. I don't want to move my entire lib to brew as it's not really the responsibility of the lib to do this IMO, and it's gonna be a drain on the ecosystem to maintain that kind of thing. So, I feel like this is closest to being Marathon's scope.

I was wondering the feels on there being a way to infer "this SwiftPM package" + "this binary" via marathon IMO. E.g.

brew install marathon-swift
marathon install danger/danger-js

Where it checks if a Package.swift exists with .executable(name: "...", targets: ..), builds them, then installs those CLI tool. My swift is rusty, so it'd take me time to build it - I figured I'd ask rather than just do it and try PR 🍡

[JohnSundell]

Could a Marathonfile be the solution here? 🤔

Marathon can already install remote scripts using the syntax you mention - it can infer GitHub URLs if you give it an owner/repo combination - but it's limited to a single Swift file (currently, that could always be changed). But, you can reference other frameworks/files using a Marathonfile. That way, you could have a repo with the single script file that is installable through Marathon, which then declares a dependency on your framework and any other files it needs - Marathon will simply download those as well and include them when compiling/editing your script.

Could that would work for Danger?

[JohnSundell]

For example, here's how it's done for TestDrive, which consists of a single script file that has 4 framework dependencies: https://github.com/JohnSundell/TestDrive/blob/master/Sources/Marathonfile

[orta]

The bit that feels odd for me here is that a lot of features require changes in both the runner and the library, I'd have to make it a dumb script/entry-point and complex lib (everything else) - separating those into completely separate repos entire feels like a lossy abstraction to me.

Maybe this is a SwiftPM thing that I'm not quite at the right conceptual understanding yet. I'm not in a rush to do anything now though, so I'll have a think.

[orta]

Interesting, so TestDrive really is a great example of that pattern - OK, I'll give this a shot

[orta]

OK, I've re-re-thought, and come back to the idea that this should work.

I feel like Danger Swift is the same kind of scope as Marathon and is structured the same - it's obviously not possible to self-bootstrap but I really feel like there should be something else that makes handling swift PM executables easy.

[JohnSundell]

The only thing we really need to enable Marathon to install pretty much any Swift PM project is to enable it to remotely install a script/project with multiple files. It already works for local scripts, but for remote ones you get an error if you try to install a script from a repo that contains multiple Swift files.

The only thing (as far as I can think of now) that we really need to implement in order to make this possible is some way for Marathon to tell which script is the "main" entry point. Maybe an initial implementation could be to simply default to main.swift if it exists and just install that? 🤔

[orta]

Could it be if there are multiple files marathon does swift package dump-package on the Package.swift and checks if they contain any executables? Then in theory you can have any amount of files per product

[orta]

Moves away from "scripting" in the sense of a quick one-off, but does leave a larger space for apps which are scripty. Things like SwiftFormat/SwiftLint/R.swift should be installable via marathon then

[JohnSundell]

Yeah it's super interesting 👍 Using dump-package could definitely be a solution, I can look into different options tomorrow 🙂

[JohnSundell]

Have been busy for the last few days, but will definitely find time to look into this over the weekend. Will keep this issue up to date with what I come up with 😄

[orta]

Never feel guilty for not doing OSS 👍 🥇

[SD10]

Definitely not my area of expertise but I'll try and learn more over the weekend 😅 Thank you both 🥇

[JohnSundell]

PR here: https://github.com/JohnSundell/Marathon/pull/125. With this, any executable Swift package can now be installed directly using Marathon 🎉 Very few changes needed to be made, since what Marathon does is basically just to generate Swift packages for scripts, so it's inherently SPM compatible 🚀