Closed ghost closed 9 years ago
Thanks @bucaran but honestly, I feel like they are too different. Although I like wahoo, I don't like how it handles packages. I like how our packages are reliable: e.g. the repo will always be there, no matter if the user closes their account on github, omf collaborators check the code so we can check for bad code designs and hacks.
If wahoo would like to change some of its design decisions we could merge. If so, ping here and I'll open some issues on wahoo on things we need to work on there.
too different
I feel the same way.
I like how our packages are reliable ... omf collaborators check the code so we can check for bad code designs and hacks.
I agree with you, which is why I have created the Wahoo Foundry to host official packages and themes, similar to what OMF does, but I still want to give users the choice to download and install what they want, so Wahoo lets you fetch any packages from the URLs listed in the registry as well as just git clone from whatever URL the user specifies.
I don't enforce any particular rules regarding approval of packages into the registry (although I do check the submissions source code). As for packages that are officially listed in the Foundry, the code review and check before acceptance is definitely a must do.
I'll open some issues on wahoo on things we need to work on there.
By all means do so! Looking forward to the exchange.
I agree with you, which is why I have created the Wahoo Foundry to host official packages and themes, similar to what OMF does, but I still want to give users the choice to download and install what they want, so Wahoo lets you fetch any packages from the URLs listed in the registry as well as just git clone from whatever URL the user specifies.
This is too confusing. It should be simple, either it is a official package and all you need to do is to declare it. e.g. Plugin 'rbenv' and if it is not official, you specify the repo, e.g. Plugin 'rbenv', github: 'bucaran/rbenv'.
But I like that you are now convinced that this is a better approach.
I guess the biggest challenge is, wahoo imo is a bad name. As it happened with Rails and Merb, they merged and as Rails had the best name and more users in the database they continued working together using the Rails name. If you are willing to merge and keep omf name, I think we can help each other a lot (as we used to do).
Wahoo's model is more powerful because although I didn't write an actual registry server, the architecture is so that it could be done one day and it would function similar to npm or ruby gems. You just can't do that with OMF right now.
The registry of URLs is kept inside the repo also, so I could enforce what gets accepted or not, whether I do it or not is a different thing :smile: . It could be easily done and I have done every time until now. But the system is not designed to enforce owners to code review anything.
I created the foundry just to make it convenient to organize packages and themes in one place and not clob my own gh account with repos.
I would be totally willing to negotiate how this part works, in the end this should be transparent to users. All I want is brew style:
wa g pkg_name
Which is how Wahoo does it right now and it works. So as long as we can keep that simple interface, the internals are tweakable.
The only part that I am not so sure about is the name. I think naming this framework after Oh My Zsh is a dishonor.
The registry of URLs is kept inside the repo also, so I could enforce what gets accepted or not, whether I do it or not is a different thing :smile: . It could be easily done and I have done every time until now. But the system is not designed to enforce owners to code review anything.
This is the part I don't like and I think is unnecessary. If it's official then it's inside the foundry, if it's not, use your own url if you want. But as you said, it's a matter of changing the internals as the command would still behave the same.
I don't see any problems on naming after Oh My Zsh. It's similar to fish, it sounds very similar to how some pronounce zsh, and it's not a dishonour. They are very different nowadays but that does not mean we can't have fun with it. :D
I didn't invent anything new here and that's very similar to how npm works, just that the registry is actually a web server, but the client part which is inside Wahoo already works like this. In the future we could easily create a node-based or rails-based server. I have plans for that too if possible :stuck_out_tongue_winking_eye:
That could be interesting, indeed!
I have been a long time contributor at OMF and I learned a lot from this framework.
In all the good faith that I could gather and wishing this suggestion is well taken I would like to propose a union with Wahoo.
I wrote Wahoo to push our shells forward and improve learning from OMF mistakes, so I hope you can take this
To be clear, Wahoo aims to replace OMF. On the other hand, many OMF plugins do work with Wahoo with little to no change necessary.
Reasoning
... is a decentralized package manager. We simply maintain a registry with URLs to packages. You don't even need to be in the registry
wa get <URL>
will attempt to install a package from whatever URL you provide.When Wahoo was released, OMF was still a centralized system with plugins and themes living in the same repository. They have improved since then, but each package still requires a repository in the organization, so one has to create a team for each package inside the organization.
wa
that lets you get / remove packages, switch themes, scaffold out new packages, submit plugins/themes and even uninstall Wahoo itself. There is nothing like this in OMF. This utility is already nearing 500 LOC and I am constantly improving it and fixing the occasional bug.