Closed millejoh closed 9 years ago
@millejoh Thanks for taking this on. This project is quite valuable. Is there anything we can do to help? What issues having you been running into? How do you plan on dealing with the widgets? (Also, as a side comment, the ipython notebook technology is moving in the direction of project Jupyter, I believe.) Thanks again!
@millejoh It would be very interesting to evolve your fork into something a little bit more in the spirit of http://jupyter.org/, where there is a core that is language agnostic, and then some utilities specific to the language (syntax highlighting for example).
Is there any update on the matter?
I wanted to get tkf's testing code working before submitting to melpa, but that has proven more difficult than I initially thought. There is a way in ipython-dev to specify which backend kernel you want to use, be it python, ruby or whatever, so in theory ein should be able to support that.
I still need a snazzy name for the melpa package to distinguish it from tkf's original version. ein-zwei anyone?
Although I liked ein-zwei, I think something like ein2+ would be more informative
If it ein starts supporting Jupyter, what about renaming it to one of its moons: Io, Europa, Ganymede, or Callisto. On second thought, I think the Eclipse project used those them to name their releases.
Great that this project is getting forked! FWIW I like @rocha's suggestions for names more than ein-zwei.
Working on getting ein2 into melpa via milkypostman/melpa#2245, but at the moment the maintainers would prefer that I either 1) Rename all the symbols so ein & ein2 can coexist, or 2) Get tkf to give his blessings that my fork is now the 'official' repository.
While I'm not thrilled about doing M-x replace-string 20-30 times, it may be the best way to get this into melpa. Any problems with typing M-x ein2:{yar} instead of M-x ein:?
I don't see any problem with the ein2 approach. However, as mentioned in the thread you linked to, if ein is no longer maintained and/or usable, the most reasonable thing is to replace it with your fork.
Disclaimer: I am not a user of ein. I got here because I realized I cannot use ein, and I'm looking for an alternative. I did not have the chance to test ein2 (tmp name) as well.
Nevermind ein2 - after talking to the MELPA maintainers we decided that making my fork the "official" version is the way to go since tkf hasn't been active in some time.
The PR with the update was merged earlier today so everyone should be able to update ein via M-x list-packages
.
Good luck, and let me know if you run into any issues.
Very cool, thanks for taking this over!
Thanks! This is excellent news.
This fork doesn't seems to work with password protected notebook servers, unlike the old one. Can this be added? On 16 Dec 2014 19:47, "John Miller" notifications@github.com wrote:
Nevermind ein2 - after talking to the MELPA maintainers we decided that making my fork the "official" version is the way to go since tkf hasn't been active in some time.
The PR with the update was merged earlier today so everyone should be able to update ein via M-x list-packages.
Good luck, and let me know if you run into any issues.
— Reply to this email directly or view it on GitHub https://github.com/tkf/emacs-ipython-notebook/issues/156#issuecomment-67165145 .
I hesitate to call tkf/emacs-ipython-notebook abandonware at this point, but certainly tkf has become too occupied (at least that is what I hope has happened) to continue actively maintaining this project.
There is a fork at https://github.com/millejoh/emacs-ipython-notebook that I am trying to keep actively compatible with the most recent version of IPython. For the moment anyone who wishes to use ein with IPython versions > 2.0 must download the code. To make this process easier I want to create a downloadable package that is easy to access through Emacs package manager.
I see my options as either 1) updating ein's recipe in melpa to point to my repository, or 2) create a new recipe in melpa, with a new name for ein.
My fork breaks compatibility with early versions of IPython, so option 2 might be the better solution. I would be happy to hear opinions on the matter. Also any suggestions for a new name would be appreciated. So far I have come up with either ein2 or zwei.