disable unison auto-detection in non osx environment

[ignatiusreza]

should also fix #248

I'm using this in an ubuntu machine, though I had managed to install unison and unison-fsmonitor manually from source (which was working in 0.1.5), new check for phython and macfsevents makes docker-sync unusable outside osx..

This is the lease that we can do to make it runnable again..

[EugenMayer]

Before merging support for any other OS, which opens a box of pandora, I would really need to understand why you ever would run under Linux? Is this cygwin, so windows or the win 10 Ubuntu shell? If yes, could we make a deal on this?

Are you willing to maintain this spin off within docker-sync? I would need somebody to opt in on this, since I am not planning to boot a Windows to reproduce issues.

[pushontom]

I'd be happy to help where possible. @ignatiusreza are you willing to help also?

[EugenMayer]

Please extract the method to detect if it is "not OSX" into a tool method, so we can use it anyway needed

[EugenMayer]

i want to release a 0.2.1 version today evening, would be nice to have an answer this, if you guys want to have this included. @pushontom thanks for opting in, but i will need @ignatiusreza to join the squad since you he seem to already have quiet some knowledge in this field

[ignatiusreza]

I'm running a full fledged ubuntu 16.04 LTS.. while the team that I'm working together with has most people working in osx.. and we're sharing the same code base.. we're using docker-sync since osx people have sever issue with performance.. but it comes at the cost of not being able to run docker-compose without docker-sync.. even though, yes, it is possible to keep several different docker-compose configuration files, doing so will makes running command more cumbersome since we have to constantly point to which configuration should be used..

with that said though, I would like to make sure that the expectation is set, as I don't want to disappoint anyone if I were to join the team officially.. maintaining open source projects are huge responsibility.. in related to this project, I know ruby, I know rails, I have some running knowledge of ubuntu environment, but, in related to unison, what I know is limited to what I've needed to do to get docker-sync running in my environment.. so, I would need either some help from existing collaborator to get up to speed, or time to do some learning.. if you're okay with this, then I'll be glad to help..

and I would also have to say, that what I did in this PR is really the bare minimum required to make it runnable again.. but it's in no way good in term of long term maintainability.. if we're to make it official that the project does support non-osx environment, then I would like to restructure some part of the code, to make it so that os dependent part are either injected or is implemented using some sort of provider pattern..

[ignatiusreza]

Please extract the method to detect if it is "not OSX" into a tool method, so we can use it anyway needed

there's a gem which would be useful for this sort of thing: https://github.com/rdp/os

do you mind if we add it as dependency?

[EugenMayer]

Providing you help with knowledge around unison / tools we setup here, is no issue and expected, so i am happy to welcome you helping out.
I would second you that trying to make docker-sync x-platform needs redesign, since i never build it that way.
I did not really see any need of docker-sync under linux, and i still do not ( linux just does it right, so its useless ) unifying the experience of OSX / linux developers using when start/command tool, while differing between docker-sync / non docker-sync is fairly easy.

that said, running under windows natively is out of scope for me completely, but running it under the new ubuntu shell or cygwin is probably one of the more interesting point to get linux support on board and also help people really need a solution.
I am not sure how far the ubuntu shell runs on a windows kernel, so needs docker sync at all, but i expect it to have a overlayed windows kernel, so docker will not run there, it will run emulated - thus in need of docker-sync.

Lets put this effort into a different branch, feature/windows-linux and we will rather release it as a beta under 2.5, not 2.0 . I really need to see how this turns out before giving user something i rather would take back or cannot maintain.

Do not get me wrong at all, i am not a OSX evangelist, i just use what i need / have and thats it. docker-sync was designed to solve a specific pain point for lets 70% of the audience. Not 100% since it will become unmaintainable, cluttered and in the end, ends up being dead for 100% :)

OS gem:
Well this makes sense ,lets pick it up. Seems to be well known and spreaded, arround for some while

[ignatiusreza]

sounds good to me.. so this PR is basically a no go, and we'll discuss and reconsider it more in a new feature branch?

[EugenMayer]

Well lets try to make the first step, how to detect os and how to implement os-specific features / branches a more general topic, before we move on with this. So the logic in here makes sense, but we need to setup the "frame" to work in ( and thats a bit more work ). Closing the PR would therefor makes sense, but we will reuse the fix later on.

Thank you for the effort!

[EugenMayer]

I added you as a collaborator @ignatiusreza, so welcome on board! feel free to create the feature branch and start working on the general stuff. If you like, open an issue for the general "OS specific speration issue" e.g. if you use kind of strategy pattern per aspect, e.g. "strategy for preconditions" / "strategy for configuration loading"

[ignatiusreza]

Thanks @EugenMayer ! Let me study the code base a little bit more to get better understanding on how things are currently organized..