Plans for homebrew adoption?
Closed this issue · 9 comments
I am integrating unox for a 2-way sync on OSX in https://github.com/EugenMayer/docker-sync and struggle to offer the people convenient methods to install unox.
E.g. things got worse, since you switched from macfsevents to watchdog, but you have no versioning. Though i cannot change https://github.com/EugenMayer/docker-sync/blob/master/lib/docker-sync/preconditions.rb#L51 to reflect that if unox < this install macfsevents otherwise watchdog. Now i just always install both to not break it for "legacy users"
In general, people struggle quiet a lot with unox due to those facts and rather use rsync since you can install all its dept using homebrew ( fswatch ).
Is there any way we could join forces to make this easier - but the official way, not me spinning of a partial solution?
Hi, I don't really have the bandwidth for this and I don't use unox myself anymore. If you want to be it's new official caretaker you can just fork it and I'll just redirect to your repository as the new official one.
Or I'll just add you as a contributor, I guess that's easier.
Thats great, lets keep work here, you initiated it here, so why drag it away :) i will look into how we could bring this into homebrew.
Any policies you have on this repo right now? ( branche layout or whatever ) ?
went forward and created two new releases 0.1.0 ( old legacy layout ) and 0.2.0 ( new brew / setup.py / pip layout ).
The latter is in a branch https://github.com/hnsl/unox/tree/0.2 so that the master if used does still not changed, since i had to move unox.py
Also, made a pull request for you to oversight the readme changes for the homebrew-installation tutorial. Since unox is basically only used under OSX, i guess that makes a lot of sense.
What do you think?
Nah, I have no policies at all. Knock yourself out. :)
I think making it homebrew-centric definitely makes sense, it's OSX after all.
@hnsl any thoughts on how to deal with the 0.2 branch - that will be the version user will start installation when using brew.
Shall i for now switch the current "github working version / HEAD" so people see what they actually install, why still keeping the master as legacy, so automated scripts sill work for a while?
The problem is, i do not see how to migrate those people. I cannot inform them, so in the end, when i merge all those things into the master, they will find out by running into errors.
I should probably also describe the pip install way now, since that is possible and easiert with 0.2.
Any thoughts on the transition? How many people do you inspect this lib to use from scratch in automation
The problem is, i do not see how to migrate those people. I cannot inform them, so in the end, when i merge all those things into the master, they will find out by running into errors.
Use your own judgment. :)
I should probably also describe the pip install way now, since that is possible and easiert with 0.2.
SGTM
Any thoughts on the transition? How many people do you inspect this lib to use from scratch in automation
I have no idea. :)
adoption finished, merged into master and homebrew provided
Nice!