Open takluyver opened 8 years ago
Since you've done most of this work, I'm happy deferring to you on the decision. My inclination would be 1., and let the two develop separately, but if the shared code is sufficiently large / complex, restoring the IPython dependency might be the simplest choice (4.). If any of the shared bits are sufficiently generic for building PT applications, we could also consider pushing some upstream to PT.
I think my inclination is to stick with 1 for now and see how we get on. If we decide we do want to share code, 4 is my preference of those options. I think most of the code is to fit PT to our systems and the expectations users have from previous versions of IPython/JC, so it's probably not that useful upstream, but there may be bits that can go that way.
Sounds like a good plan.
I'm ok with 1. I think that the console is not that much use, and that we should admit it's a stale project. If there is a real interest in the console we can revisit that. But I think we don't have the cycles right now.
In general I agree with 1, altought I guess my preferred option would be 4.
FYI, I'll make a release soon (likely today) as I do want feedback as otherwise I can' trelease IPython that breaks old console install.
FYI, I'll make a release soon (likely today) as I do want feedback as otherwise I can' trelease IPython that breaks old console install.
Ok, that was fast, I just need to git push
and twine upload
and it would be released.
I'll wait a bit, to to give you a chance to veto. Not sure ti requires an announcement (or we can bundle it with IPython when we release it)
Go for it. There's always 5.0.1.
Yeah, I think it's fine to go for it. Let's bundle the announcement with IPython, since the major change is the same for both.
I'm ok with 1. I think that the console is not that much use, and that we should admit it's a stale project. If there is a real interest in the console we can revisit that. But I think we don't have the cycles right now.
@Carreau Can you elaborate on what you mean by the console being stale/not much use and what implications that has? I ask because my use case very much depends on having an IPython kernel that I can work with both as a traditional shell and via message passing (using https://github.com/ivanov/vim-ipython).
jupyter console
isn't generally used as much as either the notebook or terminal IPython (which works in a single process, with no frontend/kernel separation). As such, it doesn't get the same level of attention. It's still something we support, and we're happy to see interested users like yourself contributing improvements, but it's not the focus of our development effort.
As we've switched both jupyter_console and IPython over to prompt_toolkit, we've got quite a bit of similar code between the two terminal interfaces, and it's at risk of getting out of sync, mainly as we make changes in IPython. We deliberately changed j_c not to inherit from IPython, because it made it much easier to understand what the code was doing: there's a lot of complexity in IPython that isn't needed for a Jupyter frontend.
Options I can see: