search

buildfoundation / mainframer

Tool for remote builds. Sync project to remote machine, execute command, sync back.
Apache License 2.0
1.73k stars 162 forks source link

Consider distribution via custom Homebrew Tap #32

Open arturdryomov opened 7 years ago

artem-zinnatullin commented 7 years ago

TL;TR of our private discussion of this thing: I'm personally kinda not sure about that, we'll have to be very conservative once we release mainframer to something like Homebrew since we'll need to provide a lot of backward compatibility which is not that easy when you write in bash.

Good example of such a problem is git, it has lot's of weird things (though I love it) because of backward compatibility.

thevery commented 7 years ago

@ming13 you can probably contribute formula into central repo

artem-zinnatullin commented 7 years ago

@thevery hello there lol 😸, surely we can, but it's more a question of "should we"?

I see this very similar to things like gradlew and other kinds of wrappers, how would you keep all team members up-to-date? What if we release v3.x with breaking changes, how would we update it in homebrew/etc without breaking it for old users?

Another point is that team members don't have to install anything to make it work once it in the project repo, while with brew/etc it's an additional step for everyone.

Moreover, once we publish mainframer into homebrew, we'll have to do the same for all Linux distros which is much more complicated…

ghostbuster91 commented 7 years ago

I like the idea of having sth like mainframer wrapper which will work analogically to gradlew.

In such aprroach you don't force users to update but still they can do it very easly.

artem-zinnatullin commented 7 years ago

Yup. mainframer.sh itself already works as gradlew so we don't need to change anything for now.

ghostbuster91 commented 7 years ago

I was thinking about something else. The mainframerWrapper could delegate all normal invocations to mainframer.sh, but in addition it could check some mainframerWrapper.properties file (where there version of mainframer would be defiend) and update mainframer.sh if needed.

artem-zinnatullin commented 7 years ago

Hm, that's interesting, let us think about it for couple days

On Fri, Jan 27, 2017, 19:40 Kasper Kondzielski notifications@github.com wrote:

I was thinking about something else. The mainframerWrapper could delegate all normal invocations to mainframer.sh, but in addition it could check some mainframerWrapper.properties file (where there version of mainframer would be defiend) and update mainframer.sh if needed.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/gojuno/mainframer/issues/32#issuecomment-275710843, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7B3JneXKSk2akefQC-6K2-7TOsTMr-ks5rWh3pgaJpZM4LUCvK .

AndreasBackx commented 7 years ago

@artem-zinnatullin I was thinking about writing Mainframer in Go. It's easy to provide binaries for every system that way. Making backwards-compatible changes are also a lot easier because of all the benefits you get when using almost any programming language. There would also only be a single binary.

artem-zinnatullin commented 7 years ago

That would require us to make ssh and rsync compatible clients which is much more complicated than current version of Mainframer. Or you want to call ssh and rsync from it? If so, I'm not sure benefits worth it %)

Also binary will be heavier than text file in terms of size and would require to make some kind of wrapper (like gradlew) which basically removes all the benefits of rewriting Mainframer from bash to other languages since we'll still need some shell.

On Sat, Apr 15, 2017, 17:05 Andreas Backx notifications@github.com wrote:

@artem-zinnatullin https://github.com/artem-zinnatullin I was thinking about writing Mainframer in Go. It's easy to provide binaries for every system that way and making backwards-compatible changes are a lot easier because of all the benefits you get when using almost any programming language. There would also only be a single binary.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/gojuno/mainframer/issues/32#issuecomment-294295408, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7B3CCvqyXb4s34mlRmIxIQHcMW6mUEks5rwM6ygaJpZM4LUCvK .

AndreasBackx commented 7 years ago

For a simple port I'd start with simply calling ssh and rsync from it. In the future we could implement these directly using Go libraries and the benefit would then be that no setup is necessary on the client machine and it could be made cross platform. We could have brew install mainframer and it would be ready for use, the same applies for other operating systems. (Linux and MacOS do tend to have ssh and rsync installed, it would be good for Windows users at least.) Using Go would also allow us to extend mainframer more easily, we could then add commands, more easily write tests, etc.

I do think that the size of binary is negligible, it would then be system-wide and not per-project. Could you explain why you would want to create a wrapper for mainframer when using a binary? I don't see a mainframer as an essential part of a project.

artem-zinnatullin commented 7 years ago

Update: we're considering publishing Mainframer to brew and other repos in some near future since tool is so mature and stable now that it's hard to work on projects without it (it's like git/etc).