xonsh
Refactor into xoretribs
Several builtin functionalities aren't necessary for xonsh to be usable, just useful. These should be refactored into stand alone xontrib-like modules: xoretribs (xonsh+core+contrib).
They are structured and loaded like xontribs, but they don't appear in the xontrib registry, cannot be managed through the xontrib command, and are loaded at startup unconditionally. (After core initialization and before rc files.)
The biggest requirement is that xonsh must still load and run commands without a xoretrib.
- [ ] VCS support
- [ ]
which - [ ] History
- [ ] Most of the builtin aliases?
- [ ] Completions
(Note: I'm not saying that you'd ever want to use a shell without these, just that the shell can run without these.)
The goal is to provide better modularity within xonsh, so that different aspects depend less on each other. Hopefully, this should 1. reduce code complexity, 2. Improve APIs, and 3. improve the experience of developing actual xontribs.
For community
⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment
(This is another reminder issue. I'll probably do this myself, I just want it out there that it's going to happen.)
I am 100% for more modularity. But just out of curiosity, what are you thinking in terms of implementation? I think it still makes sense for many of these pieces (perhaps on a case-by-case basis) to have their implementation in xonsh/ and then provide a xontrib shim for loading and unloading. Moving the implementation to a xontrib would be kind of annoying for xonsh-as-a-library.
Also to the same degree as history, you can also add completion.
I figure moving them into xonsh.xoretribs or xonsh.xoreutils, and just using an __init__.py to import them. (We can also amalgamate then, unless we go crazy with subpackages.) This is pretty similar to what xontribs does, except for updating the shell context.
Yeah, the specific completion implementations can be moved as well, but not the completion framework itself. I'll add that to the list.
Things I don't think should be moved: Parser, executor, initialization, the xontribs system (even though it could), the completions system, shells, jupyter support.
Another aspect should be that APIs used by xoretribs should be public, and they should be valid as xontribs. eg if someone is looking to write a xontrib, they can also look at the xoretribs as examples.