Marathon icon indicating copy to clipboard operation
Marathon copied to clipboard

Marathon only works with dependencies named the same as the Package

Open bitwit opened this issue 6 years ago β€’ 3 comments

I have a swift package I'm trying to import as an inline dependency. However, it is one of many within the same Package.swift and is not named the same as the Package.

When Marathon runs, it ends up pulling in the library by the name of the Package rather than the specific library name listed in the import.

i.e. import SlurpXCTools // marathon: https://github.com/bitwit/Slurp.git ends up adding the Slurp library as a dependency instead.

Ideally, I'd actually like to be able to import multiple libraries from the same Package. i.e., both Slurp and SlurpXCTools.

Am I missing something or is this a current limitation? If so, I'm very open to working on this feature. I've already been diving into the code to looks for ideas only implementing this if needed, but any guidance is appreciated.

Thanks

bitwit avatar Nov 08 '18 02:11 bitwit

After more investigation, I'm sure this is not currently possible because the packages are fetched using the git URL alone.

I'm working on a solution to allow multiple dependencies from one Package.swift here: https://github.com/JohnSundell/Marathon/compare/master...bitwit:multi-dependency-package?expand=1

I think I'm on the right track, but there's still some clean up to do. It also seems that the way packages get initially fetched is not the most efficient (i.e., updating all the packages one dependency at a time), which is a bit unnecessary when they use the same URL

bitwit avatar Nov 08 '18 03:11 bitwit

Supporting ideas like this might push Marathon towards becoming a dependency manager like Carthage. If these kinds of features do become necessary then I would be more inclined to suggest Marathon become dependent on Carthage.

ghost avatar Jul 11 '19 18:07 ghost

Yeah, it takes a lot to fix the issue. The whole dependency management aspect of Marathon is kind of thin and falls apart if you have a lot of dependencies or other more complex dependencies such as the subject of this issue. It also gets funky if your dependencies have shared subdependencies at different version levels 😱 I spent a lot of time playing around in the PR I associated with this issue and ended up disabling a whole caching layer to get the results I needed too.

So long story short dependency management is tough and I think how a tool like Marathon accomplishes it is a big discussion. At some point if your script has complex enough dependencies it’s probably better to write it as a normal Swift executable and not fight Marathon.

On Thu, Jul 11, 2019 at 2:16 PM BowdusBrown [email protected] wrote:

Supporting ideas like this might push Marathon towards becoming a dependency manager like Carthage https://github.com/Carthage/Carthage. If these kinds of features do become necessary then I would be more inclined to suggest Marathon become dependent on Carthage.

β€” You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/JohnSundell/Marathon/issues/191?email_source=notifications&email_token=AAFMXM3XQAUJDBTACEHWZZDP652G5A5CNFSM4GCPOPZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZXRNDA#issuecomment-510596748, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFMXM5UH5ZSP2A3JUZ6YADP652G5ANCNFSM4GCPOPZA .

bitwit avatar Jul 12 '19 22:07 bitwit