Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
When I introduced Marathon almost 2,5 years ago, my goal was to provide a simple abstraction on top of the Swift Package Manager in order to make Swift scripting simpler. However, as both the Swift Package Manager has evolved to make scripting much easier (thanks to features like
As you might have noticed from the lack of activity on this project's issues, I also don't have the time required to support this project anymore, especially since I've now personally moved all of my Swift scripts to use the Swift Package Manager directly. I really love to build things for the Swift community, but I also need to prioritize what I spend my time on, just like everyone else.
That being said, I'm going to try to do my very best to make the process of migrating from Marathon to another solution as easy as I possibly can, for everyone using it.
So, my question to you is - how can I help? Would you like a Marathon-to-SwiftPM migration guide? Recommendations on alternative tools to use? Maybe a tool that lets you export your existing Marathon scripts as Swift packages? Let me know by replying to this issue, and I'll do my very best to help.
Marathon isn't going away tomorrow, but I'm no longer doing any active development on it. I will make the changes required to make it fully support Xcode 11 when that ships later this year, but that's the last thing I'll do. I'm of course more than happy to accept PRs, and if you want to keep evolving Marathon for your own purposes, then you can always fork it and keep iterating on it that way.
Thanks so much to all of you who have used, discussed, and helped me work on Marathon during these past 2,5 years - it's been fun, but I think all of you will (just like me) enjoy the much simpler workflow of just working with SwiftPM directly, without any additional dependencies or layers of abstraction.
The problem this project solves for me centers around running swift from command line
Eg. I want to use alamofire from terminal
It isn't apparaent to me how this is possible just using swift package manager to spit out a terminal app.
Also - consider that there's dozens of talented developers who would love to contribute and that this project need not be a burden that you must do everything. You just need to appoint key contributors
if I can get pinned versions / then this would ensure some project longevity
@johndpope You don't need Marathon to use Alamofire from the command line. There are instructions how to use it with SwiftPM in Alamofire's README, and there's extensive documentation on SwiftPM and how to use it to build a command line tool here.
Basically, anything that Marathon can do, SwiftPM can do, because Marathon is just a wrapper around SwiftPM. That's why I personally don't see the point in continuing to work on this project. For example, why spend engineering time on re-implementing pinned versions, when SwiftPM already supports this feature out of the box?
That being said, if there really are dozens of developers who want to work on this project (like you said), then these developers are more than welcome to fork Marathon, and get together to continue working on that fork. But I seriously doubt that's going to happen, given the current state of SwiftPM and its increased maturity.
I also want to point out that I think this is a really good thing. When a tool is no longer needed, because the API or tool that it wrapped has matured, that's awesome. It's a big win for everyone - the maintainer(s) don't need to maintain the 3rd party tool anymore, and the official tool has become better for everyone. That's what I think has happened here with SwiftPM, which is why I made the decision to deprecate and stop working on Marathon. It simply isn't needed anymore.
Doing some digging
swift package init --type=executable
I think this will accommodate my immediate needs.
These new features could extend life line / and I’m not opposed to throwing out all the code. Maybe it’s a new repo....but If these new features tickets were labeled ‘help wanted’ and there was a desire to have swift virtual environments at OS level - then you’d think this would still be useful for years down the track. Or maybe I’m missing something.
Update - an out dated attempt to run swift virtual environments
The implementation between virtualenv and miniconda from ux pov are worlds apart.