oh-my-fish / oh-my-fish-legacy

Oh My Fish!
MIT License
13 stars 2 forks source link

Let's consolidate into only one Fish Framework. #498

Closed ghost closed 9 years ago

ghost commented 9 years ago

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

Oh My Fish! was a great project and I learned a lot from it and I am still a maintainer and top committer. I rebuilt many of OMF core, help rebuilt the installation system, added many plugins, improved the docs and wrote the test framework (twice), but after much suffering and dealing with a large code base, inconsistent design and poorly written plugins I decided I needed to move on and wanted to apply all this knowledge to create a new, simpler yet more powerful framework.

bpinto commented 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.

ghost commented 9 years ago

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.

bpinto commented 9 years ago

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).

ghost commented 9 years ago

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.

bpinto commented 9 years ago

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

ghost commented 9 years ago

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:

bpinto commented 9 years ago

That could be interesting, indeed!