Split into xontribs? about oh-my-xonsh HOT 3 OPEN

I too stopped using OMZ, but I switched to Prezto because of all the zstyle completions and whatnot were too much for me to implement on my own and didn't seem to exist independently of the framework. I think that's a lot of what I like about Xonsh, and by extension, this project. OMX can exist unencumbered because Xonsh has a lot built in already, and xpip and xontribs are already a mature concept.

The main OMX repo may need to remain just as a host of the org level README. I've got PyPI set up now and up is a published Xontrib. Let's keep moving in that direction until we get enough of the guts of OMZ recreated in OMX and then I can begin to transition this repo.

from oh-my-xonsh.

@agoose77 - You're reading my mind - I agree that Xontribs is absolutely the Xonsh way to evolve this where the Oh-My-Xonsh org functions similarly to Oh-My-Fish or Zim. However, I did not start that way because there are a few challenges that I needed to punt on to get something out the door. As I see it, here are some of the main questions I need to figure out to move in this direction:

1. For commonly named plugins like "git" or "python" or "golang", should the OMX org really be the owner of "xontrib-git". Or, would it make more sense for these kinds of "make-a-bunch-of-aliases" plugins to be named "xontrib-omx-git"?
2. If some plugins need to be named with an "xontrib-omx-" prefix, should all of them follow that convention? It feels clunky, but I don't currently have a better idea.
3. What's the right implementation for the main oh-my-xonsh metapackage repo? How much should it really do?
   1. Should it standardize configuration options? Or should it leave it to the package maintainer? (eg. things like "omx.config.git.skip_aliases = True"?)
   2. Should it just simply be a wrapper around "xontrib load" which maintains an inventory of OMX repos? Providing commands like "omx list", "omx load", etc.?
4. Should omx itself be a Xontrib? Is that inception level crazy? Could that even work?

Also, I'm keenly aware that projects like Prezto and Oh My Zsh, for all their flaws, feel cohesive while projects like Oh My Fish and Zim feel disconnected and pieces don't all work well together or not at all. Oh My Fish especially has too much in its main metaproject that makes it hard to use pieces without the whole, and many of its plugins rot on the vine and don't work anymore as new Fish releases deprecate features.

I think this is do-able and the right path, but I feel like I need some community input to make sure we go in a direction that will be sustainable long term.

from oh-my-xonsh.

1. If we're aiming for a one-to-one faithful reimagining of oh-my-zsh, then I think we should certainly prefix these plugins with a namespace, e.g. xontrib-omx-git → xontrib load omx_git.
2. I think keeping everything under the same namespace is fine. Many projects do this to make it clear where they come from. In general, the omx xontribs will probably be geared towards oh-my-zsh design choices, so it makes sense to clarify that up front.
3. Actually, the oh-my-zsh project itself probably doesn't need a xontrib - it seems like all OMZ really does is provide a plugin system, which xonsh does out of the box (via xontrib load). I would go as far as to say that we don't need oh-my-xonsh/oh-my-xonsh. I don't think we want to re-invent the wheel for the same of small UX gains; OMX should be an opinionated set of xontribs centred around xonsh itself.
4. (See 4)

How does this sound?

I stopped using OMZ directly some years ago in favour of zinit + OMZ plugins. For me, the plugins themselves were the feature, and OMZ's plugin mechanism actually caused issues (synchronous loading). Avoiding the same mistake here would be useful, I think!

from oh-my-xonsh.