Open agoose77 opened 2 years ago
@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:
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.
xontrib-omx-git → xontrib load omx_git
. 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.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!
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.
Hi! This is a cool repository, it's great to see all of these features replicated for xonsh. As far as I can tell, the the
oh-my-xonsh
xontrib is really just a metapackage that implements its own loading mechanism, and bundles some useful xontribs. Would you be averse to dropping the plugin mechanism, and instead publishing each plugin as its own standalone xontrib. Where plugins depend upon one another we could leverage Python dependencies.oh-my-xonsh
would become a metapackage that just requires all of these xontribs.