search

jupyter / jupyter_console

Jupyter Terminal Console
http://jupyter-console.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
250 stars 145 forks source link

Code duplication with IPython #89

Open takluyver opened 8 years ago

takluyver commented 8 years ago

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:

  1. Live with it - the benefits of having two codebases that can evolve separately may well outweigh the downsides of duplicated code.
  2. Re-inherit from IPython - I really don't want to do this.
  3. Make a separate package of 'IPython & Jupyter prompt_toolkit related stuff' - this is in some sense the best way to represent the real relationship of dependencies, but it would be yet another thing to release, and would make it harder to improve either interface quickly.
  4. Make a PT-interface module within IPython, and use that both in IPython and in jupyter_console - a compromise between 2 & 3.
minrk commented 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.

takluyver commented 8 years ago

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.

minrk commented 8 years ago

Sounds like a good plan.

Carreau commented 8 years ago

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.

damianavila commented 8 years ago

In general I agree with 1, altought I guess my preferred option would be 4.

Carreau commented 8 years ago

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.

Carreau commented 8 years ago

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)

minrk commented 8 years ago

Go for it. There's always 5.0.1.

takluyver commented 8 years ago

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.

wilywampa commented 8 years ago

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

takluyver commented 8 years ago

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.