Removetwisted #325
Removetwisted #325
Conversation
|
Does this mean that the newparallel scripts should just be ipcontroller/engine/cluster, and not with the 'z' suffix, since kernel and newparallel will not coexist? |
|
The thinking at sage days was that the old parallel stuff would be kept around but deprecated in 0.11, so that people can upgrade to it and then start changing their code to the new framework. |
|
Min, Fernando and I talked yesterday and decided it would be best to Brian On Thu, Mar 31, 2011 at 3:35 AM, takluyver
Brian E. Granger |
|
Ah, I see. Maybe we should codename 0.11 "a new dawn" ;-) |
|
Or for that matter, maybe we should skip right by 1.0, and just go straight to IPython 2.0. It would be more representative of the amount of work in 0.11. |
|
Thomas, I think we should call it 0.80 or something, indicating that we're preparing for 1.0 but there may still be some api shakedown. The idea will be:
How does that sound? Brian, thanks a lot for doing this! This is phenomenal :) |
|
I don't like 0.80 - it's too liable to be confused with 0.8. I prefer Min's idea of working towards a 2.0 release. IPython as I'm already using it (0.10) is a perfectly usable and working "1.0" solution. So I suggest we call the next release something like 1.9, then have a series of bugfixes and stabilisations leading up to IPython 2.0. |
|
That sounds fine to me. 0.11 just seems too small. |
|
matplotlib did 0.99.x for their stabilization stage. We are considering an extra stage prior to that. Maybe 0.88.x? That won't be confused with 0.8. |
|
Sure, 0.88x sounds like a good plan. |
|
0.88.x is more clearly distinguished, but... I don't know, it just seems a little ridiculous. I don't think there's any way to do sensible version numbering leading up to a 1.0 release down the line. Also, how much of the codebase has been refactored or rewritten, I think you were right that 2.0 is a more accurate way to describe it. |
|
I am still not satisfied with the versioning. 0.88 seems almost arbitrary and 0.99 implies we very close to 1.0 (not quite there). I am almost thinking that just sticking with 0.11, 0.12, etc. until we are really thinking about 1.0 makes the most sense. |
|
Sure, we can stick with 0.x if there are objections, it has the inertia, but I think we are really thinking about 1.0. Even if we are sticking to 0.11 with newparallel and config in April, and 0.12 with htmlnotebook very soon after, I think that 0.99 (or whatever we decide to call pre-1.0 preparation) would come immediately thereafter. I expect (or at least hope) that this will happen in 2011. New things IPython 1.0 will have, not in 0.10:
I see two options here. Either we consider 0.99.0 as the point where we don't mind breaking everything in preparation for 1.0 (what we are doing in 0.11), or we jump to 0.99 the instant we are 1.0 feature-complete (not bug-free, just having a releasable version of all new features), and consider it strictly stabilization and cleanup. I like the former, because it better prepares users for the changes they will face in an update, but the latter makes sense too. I don't think too many users would expect approximately zero API compatibility between 0.10 and 0.11. I checked matplotlib's history, and they had a 0.98.x series prior to 0.99.x. I think this is better than 0.88, other than Fernando's comment that 0.88 is 0.11, but 8 times as awesome. Other options are: jump a short distance to 0.20, or say we are halfway there with 0.50. If there's no consensus, let's stick to 0.11, but I would vote for approximately every other proposal so far before 0.11. |
|
I'd support 0.98.x/0.99.x, i.e. 'nearly 1.0', or 0.50.x as 'a big jump from 0.10.x'. |
|
matplotlib had a 0.51, 0.52... series half-way through the transition too. Honestly I don't really care much. We're burning pointless cycles here, which means we should simply stop worrying about this, keep going with 0.11, etc, and one day call it 1.0 as soon as it's ready. We have better things to spend our time on than endlessly debating numbering schemes. It's even less interesting than bsd/gpl conversations, which at least have some interesting philosophical side-tracks... |
|
So, back to the actual pull request: Brian, do you think we should pull the trigger on this one now? In my mind, this should be merged sooner rather than later so that Min can rebase newparallel on top of master at that point. He can then adjust the startup scripts and we can simplify things. The only major thing left to do will then be the config work. I'm having a look at this code now, but I wanted to know what you guys think timeline-wise... |
| @@ -1,25 +1,6 @@ | |||
| # encoding: utf-8 | |||
| """The IPython1 kernel. | |||
| msg = """IPython.kernel has been replaced by IPython.parallel. | |||
There was a problem hiding this comment.
This should just be left as a docstring, and then the import error can do
raise ImportError(__doc__)
that way even afterwards, introspection will do the expected thing on the module object.
I also think the message here needs to be longer and more detailed, so that in addition to the above line there's a short indication of what that means and a link to the page on the docs that provides usage/transition info. Even if for now that URL isn't ready, let's put something in here as a placeholder so we don't forget later. The idea is that the importerror alone should give people enough to go on by themselves without having to ask us on-list.
|
Other than my minor inline notes, the code cleanup itself looks great, thanks! The one thing I'd like to see added right away is some note in the docs about what's going on, even if it's just a short explanatory paragraph. Because we'll want to build the docs and push a build with this information immediately to the users, so people can start preparing for it (as well as announcing it quite loudly on the lists). In fact, I'd suggest pinging the -dev and -user lists right away pointing to this pull request and indicating what's going on, so people can start preparing. Because the moment it gets merged, anyone who was running from master with twisted code (and I'm sure there are people like that, for whom it was working with local clusters) are going to be in for a really rough ride... So I think before actually pulling the trigger on this one, we really need to make an announcement on the lists, so people at least are given a warning. |
|
notice sent. |
|
Awesome, thanks! This is great to have right away... |
|
I am +1 on this being merged now. On Mon, Apr 4, 2011 at 3:35 PM, fperez
Brian E. Granger |
|
Did you have a chance to make the fixes I indicated? Also, I think we should have a note in the docs (can be short) ready to go in this pull request, so that when the merge goes in, we can immediately build the docs and have our dev docs properly indicate to people what's going on (even if the full porting doc isn't complete yet). I don't want the docs to start falling badly behind... Once these two minor things are in, go for it! The tests look good. thanks! |
|
Really looking forward to see this merged! I think all the work in ipython has been amazing so far: thanks a lot! |
|
I think my first question got lost behind the versioning discussion: Does this mean I should remove my 'z' suffix everywhere after this is merged? |
|
Yes, I think so. Although I do like all of the "All yur clusterz are mine" Brian On Tue, Apr 5, 2011 at 9:26 AM, minrk
Brian E. Granger |
|
On Tue, Apr 5, 2011 at 9:31 AM, ellisonbg
I agree too, despite the loss of comedy potential :) f |
|
I'll do this merge today (with Fernando's notes), unless someone objects. |
|
I need to fix a few quick things first... Brian On Tue, Apr 5, 2011 at 3:40 PM, minrk
Brian E. Granger |
|
Okay, sure. If you want to do the merge that's fine, but I'm happy to do it if you are busy. (I already removed the kernel scripts, and fixed the dangling check_for_x for zope,twisted,fs, and openssl in my local branch, put IPython.kernel back as a package, etc.) |
|
OK I just fixed things. This can be merged. Woohoo! |
|
remove IPython.kernel scripts and put migration notice in docs. closed by 627e381 |
|
I also pushed a new build of the docs, with a link to the new docs, rather than just a void where the old parallel docs: http://ipython.github.com/ipython-doc/dev/parallel/index.html |
|
newparallel has been rebased onto this, so all temporary 'ip___z' scripts are now back to 'ipengine/ipcontroller/ipcluster'. |
|
On Wed, Apr 6, 2011 at 2:57 PM, minrk
Awesome, thanks! |
This pull request removes the Twisted based IPython.kernel. I have tried to go through the entire codebase and remove all twisted/zope.interface/foolscap using code. This includes the test suite and setup scripts, but not (yet) documentation or examples as we need to transition those to the new zmq parallel stuff. I will add issues for that work.