⚠️ Heads-up: Deprecation
JohnSundell opened this issue · 6 comments
Hi everyone,
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 swift run), and that it's now being integrated directly into Xcode - I feel like Marathon has played out its role, and it's time to deprecate it.
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.
Good good, SPM is getting solid enough to replace a bunch of community infra 👍
The problem this project solves for me centers around running swift from command line
Eg. I want to use alamofire from terminal
https://gist.github.com/johndpope/c859925603e8f176318c1d28a1dca6fc
It isn't apparaent to me how this is possible just using swift package manager to spit out a terminal app.
https://stackoverflow.com/questions/630911/using-frameworks-in-a-command-line-tool/52249057#52249057
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
#82
I'm happy to help here - just need to expose versions in the 'releases' project.
@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
https://www.raywenderlich.com/1993018-an-introduction-to-swift-package-manager
I think this will accommodate my immediate needs.
But I still like that marathon can overarch swift environments across swift scripts.
There’s something lost when for every swift adhoc shell script you need to have an associated swift project package. I’m a big fan of miniconda which handles python packages for specific environments/ python 2/3 / you can create the environment / activate / zsh will show you the respective python virtual environment / while this repo doesn’t do this just yet, it could, and I don’t think SPM will.
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
https://github.com/ankit1ank/virtualswift
The implementation between virtualenv and miniconda from ux pov are worlds apart.
We would need to extend zsh to show respective swift environment / maybe the world isn’t ready for this yet.
Mini conda feature set
https://docs.conda.io/projects/conda/en/4.6.0/_downloads/52a95608c49671267e40c689e0bc00ca/conda-cheatsheet.pdf
@JohnSundell What about all of your other projects that rely on Marathon for installation?
@DrBeta Those installers will now be adapted to be executed using SwiftPM instead.