-
Notifications
You must be signed in to change notification settings - Fork 749
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Homebrew #60
Comments
Thanks for your suggestion! Yeah would be handy for devs working on their own on smaller projects, but devs in bigger teams with multiple projects will run in a sort of DLL-hell like problem where you have version 0.9 of R.swift for project A that is in Swift 2 and I have version 0.7 for project B that I can't upgrade because that needs to be Swift1.2 for a while. Putting the R.swift binary (that I want to convert to a Swift script btw instead of a binary, see #36) in the project folder makes sure every devs is using the correct version for that project. It also guarantees you can downgrade just one project in the case that R.swift generates invalid code for your project. So I feel it's better to see these kind of tools as "libraries" that you compose your project of and not as a tool that is installed on you Mac globally. Let me know if you disagree and have good arguments for the homebrew approach that I'm missing! |
Hmm well that doesn't really contradict your use case. You can still have it in the projects folder if you like, which makes sense for big teams. For smaller teams however, it's probably handier to install it on the computer. |
True, it would be possible to downgrade, but then again all project are downgraded/upgraded at once. Good point that you could still use R.swift in a project if you prefer that method. That would be absolutely true. I don't really see the big benefit when using Homebrew. Since new developers would have to install one more tool before getting their project up and running and taking the risk of a versioning problem. What would be your main argument for using Homebrew instead of embedding in your project? |
It's not a huge benefit, admittedly. It's just more comfortable and more what people are used to. R.swift would be the first tool I'd install in my project folder, opposed to Carthage, Cocoapods and mogenerator. |
Another advantage is that as a formula, it's easier to update R.swift itself. Then I can just update it together with any other package. |
+1 |
+1 would love to see on homebrew |
Okay, I'm convinced there are users that would use R.swift like this. I'll look into creating a R.swift formula for R.swift. :) |
@mac-cain13 any chance you've looked at creating that formula yet? |
Not yet! There is quite a lot to do and it's not my highest priority thing to fix to be honest. :) Please feel free to create a PR with a (concept) formula and some pointers how to publish it, I'm new with creating Homebrew formulas so help is appreciated and would speed things up a bit. If not I'll get to it eventually! :) |
Hi guys! I've purposed a brew formula at homebrew's formula repo. So it comes available when they merge my pr. |
Cool 👍 Let me know when it's in and ready to use! |
The PR finally got merged, so it should be in homebrew now! When I have some time I will propose a change to your readme. Happy coding y'all! |
Oh and it should be |
Tnx @tomasharkema! |
Would be cool if we could install this using Homebrew :)
Then we wouldn't need to have the binary in every single project folder.
The text was updated successfully, but these errors were encountered: