These are chat archives for ipython/ipython

12th
Dec 2014
Nathan Goldbaum
@ngoldbaum
Dec 12 2014 05:44
hi all - would anyone be interested in helping me update runipy to work under the current ipython master branch?
right runipy is dying with the following traceback: https://gist.github.com/ngoldbaum/44630f988b4cb0c0790a
anyone have a pointer for where I can look to understand how this API changed?
alternatively, has IPython grown the ability to script notebook evaluation, obviating the need for runipy?
Nathan Goldbaum
@ngoldbaum
Dec 12 2014 06:29
reported it as paulgb/runipy#48
Min RK
@minrk
Dec 12 2014 07:02
Probably a PR merged today, should be minor changes. I will look into it in the morning.
Jonathan Frederic
@jdfreder
Dec 12 2014 17:04
@Carreau that's awesome!
Maybe we can replace require with that eventually
Matthias Bussonnier
@Carreau
Dec 12 2014 17:04
yeah, and that would give us kwarg, and the rest.
Jonathan Frederic
@jdfreder
Dec 12 2014 17:04
I think it'll have to wait till there's an optimizer for the es6 modules though
(assuming there isn't one yet)
By optimizer, I mean a dependency hierarchical traverser so we can compile all of our JS into one file.
Matthias Bussonnier
@Carreau
Dec 12 2014 17:07

Building all files into one bundle
Build all ES6 modules into ES5 System.register form:

traceur --out app-build.js app/app.js --modules=instantiate

:-P
Jonathan Frederic
@jdfreder
Dec 12 2014 17:07
Oh nice
Then I suppose we could move to that
maybe we should talk about it at the next dev meeting
(for 4.0 of course)
I've been using gulp and browserify in my Poster project
They're also really nice
Matthias Bussonnier
@Carreau
Dec 12 2014 17:09
I'm wonderign how much we can mix es5 and 6.
I woudl gladely write the new modules in es6 + with the map files you get the right error line number in console
Matthias Bussonnier
@Carreau
Dec 12 2014 17:19
OK, I'll stop early today, I didn't slept last night.
I might merge a few PR for the thrill
Jonathan Frederic
@jdfreder
Dec 12 2014 17:24
Goodnight!
:)
Thomas Kluyver
@takluyver
Dec 12 2014 18:11
Who wants to push the button on #7083? :)
Jonathan Frederic
@jdfreder
Dec 12 2014 18:18
Done :)
I'm really excited about that PR btw
It makes my extremely hacky jsobject (scipy experiment) and related things a little less hacky
thanks @takluyver
Thomas Kluyver
@takluyver
Dec 12 2014 18:22
you're welcome :)
Brian E. Granger
@ellisonbg
Dec 12 2014 18:32
@all
Kyle Kelley
@rgbkrk
Dec 12 2014 18:33
present
Brian E. Granger
@ellisonbg
Dec 12 2014 18:33
If someone is part of our Trello org, can they add themselves to any org board?
Or does an admin have to do that?the
Kyle Kelley
@rgbkrk
Dec 12 2014 18:35
I think an admin has to do it
oh wait
part of the org
yeah, I think they can add themselves to any one
I was thinking of the case where someone gets invited to a single board.
Jonathan Frederic
@jdfreder
Dec 12 2014 18:36
@ellisonbg you can ping all, but the way you did it doesn't work
It needs to be /all
so (at)/all
Kyle Kelley
@rgbkrk
Dec 12 2014 18:37
Luckily https://github.com/all is an organization, so they don't get pinged
Brian E. Granger
@ellisonbg
Dec 12 2014 18:38
Looks like there is a setting for it on the board settings. But it looks like only the board creator can change that.
There are some ways that I don't like Trello....
Jonathan Frederic
@jdfreder
Dec 12 2014 19:08
@/all how popular is the popup widget? Would anyone object to me opening a PR to remove it? It's broken with the layout manager removal.
Min RK
@minrk
Dec 12 2014 19:08
I wouldn't object to that, but probably best to ping @jasongrout or @SylvainCorlay.
Jonathan Frederic
@jdfreder
Dec 12 2014 19:09
I think they too get pinged by the /all
since they're never actually removed from the room when they leave
Brian E. Granger
@ellisonbg
Dec 12 2014 19:10
I am +1 on removing it for now
I think the popup type of thing is going to have to be reconsidered when we start to think about phosphor and such
Jonathan Frederic
@jdfreder
Dec 12 2014 19:11
Exactly
and even if we do decide to include it, I'd like to be a little more careful about it's implementation
Brian E. Granger
@ellisonbg
Dec 12 2014 19:12
The idea of the popup widget is nice, but the reality is a bit different
Yes
Jonathan Frederic
@jdfreder
Dec 12 2014 19:12
yeah
Brian E. Granger
@ellisonbg
Dec 12 2014 19:12
But I am not worried about removing it with our new annoying warning...
Jason Grout
@jasongrout
Dec 12 2014 19:21
@jdfreder: I like the popup widget...
talking about the warning: ipython/ipython#7200
@ellisonbg: I think the warning is only warranted if we split off the widgets, and then at some point want to backport semantic changes from the separate repo back to core IPython. Is that what you see happening, @ellisonbg?
Or @ellisonbg: do you see the split-off widgets repo as living inside the IPython.html.widgets namespace?
@jdfreder: just the other day I was basically reimplementing popup, but then realized that I could just subclass it from the main widgets.
Brian E. Granger
@ellisonbg
Dec 12 2014 19:30
@jasongrout it really depends on how we work the split repos. There was soem talk about trying out namespaces. But it will most definitely be a jupyter project though so minimally something like jupyter.widgets
Jason Grout
@jasongrout
Dec 12 2014 19:33
so basically, IPython.html.widgets will be frozen when IPython 3.0 is released? If that's the case, then there is no sense in warning about future changes.
if widgets continue on in a separate repo, like jupyter.widgets, then of course the api could change---it's a separate project.
Brian E. Granger
@ellisonbg
Dec 12 2014 19:36
I don't think that follows - all of our code is being split into separate repos, but a good fraction of it is quite stable
Most users who use ipython through anaconda will never know that there is a repo/package split. Anaconda will ship with all of it.
Jason Grout
@jasongrout
Dec 12 2014 19:37
A user who is importing widgets from IPython.html.widgets will not have to worry about future changes, because IPython.html.widgets is effectively frozen when the repo splits.
Brian E. Granger
@ellisonbg
Dec 12 2014 19:37
During this transition time, I think we have to go out of our way to help users understand what is breaking and why.
Except it will result in an import error in ipython 4.0 as it won't exist at all
Jason Grout
@jasongrout
Dec 12 2014 19:38
right. But that can be one of the huge warnings in the release notes for ipython 4.0
Brian E. Granger
@ellisonbg
Dec 12 2014 19:38
There will be no shim or compatability layer for imports.
Jason Grout
@jasongrout
Dec 12 2014 19:39
possibly even a deprecation warning in the last few releases of 3.x
Brian E. Granger
@ellisonbg
Dec 12 2014 19:39
But API instability is completely separate from the repo splitting we will be doing - from a user's perspective
Also, I don't view imports changing as being the same thing as high API instability where lots more changes
We have lots of APIs that will only change in 4.0 by their import being different
Of course, 4.0 will have to have a huge table showing how people need to change their imports
But the API instability of subprojects like widgets are a whole separate thing.
Part of the issue is that people have gotten used to all of ipython evolving at the same pace and having the same overall level of APi stability.
At least in theory
Nathan Goldbaum
@ngoldbaum
Dec 12 2014 19:42
Sorry to jump in, but this is an interesting discussion to me - is the plan to eventually make the widget API stable? Right now it's a bit of a pain to support widgets in both IPython 2.x and 3.0-dev, I'd hate to see that get worse with more API changes in the future.
Brian E. Granger
@ellisonbg
Dec 12 2014 19:42
But Jason - more importantly - does this warn at import approach cause a real problem from some of your usage cases (if you can disable it as you can now)?
Jason Grout
@jasongrout
Dec 12 2014 19:43
do you see the import warning happening on jupyter.widgets too?
Brian E. Granger
@ellisonbg
Dec 12 2014 19:43
Yes
Jason Grout
@jasongrout
Dec 12 2014 19:44
@ngoldbaum - there probably will be future changes in widgets
Brian E. Granger
@ellisonbg
Dec 12 2014 19:44
Hi @ngoldbaum good question. Someday the widget API will become stable. But right now it is going through major changes that will continue to increase the instability of the API for a while
@jasongrout and @ngoldbaum here is how we have started to think about it: ipython/jupyter are two separate and sometimes conflicting things:
1) A software project that has users
2) A research project that is studying interactive computing and trying to answer fundamental questions about it
Jason Grout
@jasongrout
Dec 12 2014 19:45
@ellisonbg: yes, I think I see your point better. I'll reword the message to be brief and to the point.
Brian E. Granger
@ellisonbg
Dec 12 2014 19:45
Some areas of our code base don't have many research questions - so they are more in the 1) space.
But widgets are strongly in the 2) space - we have tons of really basic questions about this type of thing - no one has done anything quite like this before
Jason Grout
@jasongrout
Dec 12 2014 19:46
well, lots of people have done stuff like this before, but we haven't
Brian E. Granger
@ellisonbg
Dec 12 2014 19:47
And the worst thing you can do in a research context is limit exploration
Jason Grout
@jasongrout
Dec 12 2014 19:47
"IPython widgets are experimental and may change in the future."
Brian E. Granger
@ellisonbg
Dec 12 2014 19:47
Imagine saying in physics or math - OK we are going to do research, but we can't prove any new theorems or do any new derivations
People have become very used to "ipython as the software project" but we need to help them understand when parts of it are more "research"
Jason Grout
@jasongrout
Dec 12 2014 19:48
(take out "API" - who's going to understand that abbreviation? take out "is still considered" -- too wordy)
Brian E. Granger
@ellisonbg
Dec 12 2014 19:48
That is the underlying message hidden in that warning
Good points!
I like your phrasing above there much better
Nathan Goldbaum
@ngoldbaum
Dec 12 2014 19:49
sure, I definitely see where you're coming from. Would you say that it would be a bad idea to integrate IPython widgets directly into another project at this point? Right now the changes haven't been too extreme (mostly the CSS changes are what I'm thinking of), but I could see it being untenable to support multiple IPython versions for some fancy widget-based functionality.
Jason Grout
@jasongrout
Dec 12 2014 19:49
and it especially showcases IPython widgets, as opposed to other widget projects
Brian E. Granger
@ellisonbg
Dec 12 2014 19:50
It really depends on the project - if you are willing to follow the changes and don't have to promise stability to your users, then it is fine. But if you have to make promises to your users about stability or can't afford to make changes often, then you have to think twice
@jasongrout yes
Min RK
@minrk
Dec 12 2014 19:51
I would expect the warning to go away when it's moved to a new repo
Nathan Goldbaum
@ngoldbaum
Dec 12 2014 19:52
thanks for the advice! we're thinking about adding something like "show_widget" to some functionality in yt, i'll bring this up in future discussions on this topic. Hopefully whoever commits to maintain it will be ok with tracking changes in IPython.
Min RK
@minrk
Dec 12 2014 19:53
A new repo with 0.x versioning can communicate more clearly that it's not a stable project in its entirety. Where there's an issue is an unstable component of an otherwise stable project.
Brian E. Granger
@ellisonbg
Dec 12 2014 19:53
Yes, I think the 0.x versioning will be an important part of this messaging.
Jason Grout
@jasongrout
Dec 12 2014 19:56

I thought:

  1. IPython.html.widgets API is frozen at IPython 3.0
  2. the widgets split off to an 0.x project, say jupyter.widgets
  3. people consider those as two separate things that can be incompatible.

It sounds like Brian thinks (3) is false, which is why he wants to warn users of IPython 3.0 widgets that the API is not stable. Is that a fair summary?

jdfreder @jdfreder is catching up with the conversation
Jason Grout
@jasongrout
Dec 12 2014 20:00
For what it's worth, @SylvainCorlay told me that he thinks there should be no user warning, but rather a developer warning printed to the javascript console.
Brian E. Granger
@ellisonbg
Dec 12 2014 20:02
@jasongrout I don't know what you mean by "frozen" in the option 1
The widgets code will not exist in any ipython branded repo or package
after 3.0
If by frozen you mean "still available in the older ipython 3.0" then yes
But if you mean "eternally available in all future versions of ipython in an unchanged state" then definitely not
Just like after 3.0 the notebook itself will not even exist in any ipython repo or package
Jason Grout
@jasongrout
Dec 12 2014 20:07
I mean that IPython.html.widgets will, if it succeeds, will not have any changes in the future.
Brian E. Granger
@ellisonbg
Dec 12 2014 20:08
But that is the point, after 3.0 it will result in an ImportError always
Obviously, there are a million things to work out, but that is the rough idea = full and complete separation of everything
Jason Grout
@jasongrout
Dec 12 2014 20:10
but really, (3) is where we disagree, right?
(and widgets and everything else will be in 3.x, not just 3.0, right?)
(by the way, better widget warning message at ipython/ipython#7201)
Nathan Goldbaum
@ngoldbaum
Dec 12 2014 20:15
@minrk thank you!
Brian E. Granger
@ellisonbg
Dec 12 2014 20:17
Yes, 3.x will continue to have everything
I am not sure how 3 even makes sense when only one of the projects will continue to exist in the long run
Jason Grout
@jasongrout
Dec 12 2014 20:24
yes, but there will be a long time (at least a year?) in which 3.x widgets and jupyter.widgets coexist.
the 3.x widgets don't change, the jupyter.widgets can change drastically
so I would say the 3.x widgets are stable (e.g., don't need a warning), while the jupyter.widgets should be version 0.00001 with large warnings about how they change daily or something.
Brian E. Granger
@ellisonbg
Dec 12 2014 20:25
But no one will have ipython 3.x installed after a very short period of time
Jason Grout
@jasongrout
Dec 12 2014 20:26
whereas I think you are saying that people will naturally see the 3.x widgets and jupyter.widgets as the same project.
Nathan Goldbaum
@ngoldbaum
Dec 12 2014 20:26
I don't think it makes much sense to advertise an API as stable if they're going to be removed in a future version
Jason Grout
@jasongrout
Dec 12 2014 20:26
"But no one will have ipython 3.x installed after a very short period of time" - do you mean just the 3.x widgets?
Brian E. Granger
@ellisonbg
Dec 12 2014 20:26
We are thinking of releasing ipython 4.0 (the completely split version) along with all of the new jupyter projects shortly after 3.0 (more like 3 months)
Jason Grout
@jasongrout
Dec 12 2014 20:27
oh. ooohhhh....
Brian E. Granger
@ellisonbg
Dec 12 2014 20:27
IOW, the next release of the project might not have any changes other than the repo/package splitting
Jason Grout
@jasongrout
Dec 12 2014 20:28
Trying to get to IPython 2015 quickly? :)
Brian E. Granger
@ellisonbg
Dec 12 2014 20:28
We haven't decided to do that for sure, but that is one option we have talked about - basically a do a very quick feaure freeze release
Jason Grout
@jasongrout
Dec 12 2014 20:28
but that makes sense.
Brian E. Granger
@ellisonbg
Dec 12 2014 20:28
We don't want the transition to go on for very long
rip the band aide off :)
Jason Grout
@jasongrout
Dec 12 2014 20:28
yes, I agree.
so that explains better why (I think) you think that people will see IPython.html.widgets as essentially the same as jupyter.widgets, and may expect stability even if jupyter.widgets is version 0.01
Jonathan Frederic
@jdfreder
Dec 12 2014 20:30
Conclusion: when we do the repo split we can remove the warning. Right?
Brian E. Granger
@ellisonbg
Dec 12 2014 20:30
And I also understand how if the two continued to exist for a long time that things would be very different
ummm, I don't think so - the warning doesn't address the repo splitting, but rather the API instability - so it will remain as long as widgets are unstable
Jonathan Frederic
@jdfreder
Dec 12 2014 20:31
What's a good measure of stability?
with the widgets in mind
Brian E. Granger
@ellisonbg
Dec 12 2014 20:32
Or at least until we feel that people see widgets as unstable in a way that is reflected in the version number (0.x).
Min RK
@minrk
Dec 12 2014 20:32
I don't think a warning on a 0.0.1 project is necessary
Brian E. Granger
@ellisonbg
Dec 12 2014 20:32
I am not sure we even know
But I think our users have grown used to thinking "widgets are in ipython 3.0"
Min RK
@minrk
Dec 12 2014 20:33
I can't think of a single example of a project that warns you that the entire project is new and experimental every time you try to use it.
I think the problem is entirely because widgets are an unstable part of a stable project. When they are moved to a separate, self-consistent project, that problem goes away.
Brian E. Granger
@ellisonbg
Dec 12 2014 20:33
Sure when projects are "new" that is assumed. But by their affiliation with ipython, people see widgets as being 13 years old
Min RK
@minrk
Dec 12 2014 20:34
That's why we are moving them to their own project
(I don't think there's a single person that views widgets as 13 years old)
Jonathan Frederic
@jdfreder
Dec 12 2014 20:35
hehe
Brian E. Granger
@ellisonbg
Dec 12 2014 20:35
From the feature prespective no, but from the project perspective I don't think users distinguish
Which is why we want to remove them from the main repo in the first place - we feel like having them there communicates a stability that isn't accurate
Min RK
@minrk
Dec 12 2014 20:36
Exactly
Brian E. Granger
@ellisonbg
Dec 12 2014 20:36
I am fine getting rid of the warning soon after splitting though
Min RK
@minrk
Dec 12 2014 20:36
removing them fixes that communication of stability
Brian E. Granger
@ellisonbg
Dec 12 2014 20:36
would prefer to have it live for a little bit in the split repo, but don't feel too strongly about that
True
Min RK
@minrk
Dec 12 2014 20:36
In any case, we can discuss the warning in the destination repo later. There's a 3.0 to finish!
Brian E. Granger
@ellisonbg
Dec 12 2014 20:37
Yep
Min RK
@minrk
Dec 12 2014 20:37
I think we are quite close
Jonathan Frederic
@jdfreder
Dec 12 2014 20:37
@jasongrout if you're still around, did you have a chance to look at ipython/ipython#7162 ?
Jason Grout
@jasongrout
Dec 12 2014 20:39
yes, I'm around. I'm busy for a bit.
Brian E. Granger
@ellisonbg
Dec 12 2014 20:44
@takluyver that rescaling issue is weird on your system
Havn't we always just doubled the image sizes for retina and it played well?
I don't have a retina so I haven't really looked into it much @minrk is the expert on that
Jonathan Frederic
@jdfreder
Dec 12 2014 20:46
Anyone interested in merging ipython/ipython#7116 ?
Min RK
@minrk
Dec 12 2014 20:46
I'll play around. image scaling is up to the browser, and there are lots of different ways to do it.
Brian E. Granger
@ellisonbg
Dec 12 2014 20:49
OK, things are scaling fine on my system (non-retina mac) scaling down a 64px high jupyter logo to 32px. But not for @takluyver maybe the difference is that the width is not a even multiple
Whereas for the square kernel logo it is64x64
Thomas Kluyver
@takluyver
Dec 12 2014 20:50
it's browser weirdness. Only happens when the dev tools are open and at the bottom of the window
Brian E. Granger
@ellisonbg
Dec 12 2014 20:50
Ahh, crap
Thomas Kluyver
@takluyver
Dec 12 2014 20:50
unless people can reproduce it without devtools open, I'd say we needn't worry
Brian E. Granger
@ellisonbg
Dec 12 2014 20:51
@minrk what is your take on the logo size question in #7199
Thomas Kluyver
@takluyver
Dec 12 2014 20:51
no, wait, I can reproduce it
it appears to be when the window height is less than a certain number
Min RK
@minrk
Dec 12 2014 20:52
That's just crazypants
Thomas Kluyver
@takluyver
Dec 12 2014 20:52
880 pixels
Min RK
@minrk
Dec 12 2014 20:52
wtf
Thomas Kluyver
@takluyver
Dec 12 2014 20:52
does that have any significance?
Brian E. Granger
@ellisonbg
Dec 12 2014 20:53
Are you sure it isn't related to thermal fluctuations on the surface of mars?
Kyle Kelley
@rgbkrk
Dec 12 2014 20:54
Ha
Min RK
@minrk
Dec 12 2014 20:55
It's when the scrollbar appears
it seems like the browser is putting the image on a half-pixel location, causing the fuzz
changing the window width cycles through sharp/fuzzy/back again
technology!
Back to the earlier question, 32px seems too big to me, unless we are significantly increasing the size of the header
Brian E. Granger
@ellisonbg
Dec 12 2014 21:07
What do you think about 28px - still bigger than master's value of 24px
I mainly think that our logo just doesn't look very good at 14px on a non-retina screen
@minrk and @takluyver looking at the PR that @jdfreder has on page reloading and widgets - #7163
Do you have a few to chat about it?
Min RK
@minrk
Dec 12 2014 21:13
sure
Brian E. Granger
@ellisonbg
Dec 12 2014 21:48
LOL @jasongrout - we just tried the new widget warning
And it made us sad
Screen Shot 2014-12-12 at 1.48.29 PM.png
What is that if __name__ == stuff?
Jason Grout
@jasongrout
Dec 12 2014 22:04
It's telling you where you imported the widget, if I got it right.
(that's the stack=2 part of the warn() call)
so it appears to not make much sense if used interactively?
It made sense when, for example, you import pythreejs (which imports the widgets)
Brian E. Granger
@ellisonbg
Dec 12 2014 22:18
Yeah, I think we want to err on interactive usage - I don't want it to appear like an bug
Can you play around with that to get rid of the extra junk?
Also @jasongrout do you want to do any more review on #7163 before we merge?
Jason Grout
@jasongrout
Dec 12 2014 22:28
hehe...I thought the point behind the warning was, in a sense, to say "hey, using our widgets is a bug in your (stable) code" :)
but I can set it back to state=1 to see what happens then.
Brian E. Granger
@ellisonbg
Dec 12 2014 22:33
OK thanks
epifanio
@epifanio
Dec 12 2014 22:36
hi can you help with this import error https://gist.github.com/58f2561318807af8d4a0
cannot import name 'ConfigManager'
on master
Thomas Kluyver
@takluyver
Dec 12 2014 22:49
@epifanio how recent is your master?
That was merged within the last few days
epifanio
@epifanio
Dec 12 2014 22:57
i did a pull some days ago, now i update gain. Checking if the error goes away
hum . no still here
epifanio
@epifanio
Dec 12 2014 23:05
@takluyver I did a git pull and reinstalled ipython, but the error persist
Thomas Kluyver
@takluyver
Dec 12 2014 23:12
are you sure you're reinstalling correctly? That class is definitely there: https://github.com/ipython/ipython/blob/master/IPython/html/services/config/__init__.py
epifanio
@epifanio
Dec 12 2014 23:16
@takluyver this is the full log : https://gist.github.com/f65e2296af62011a1d6a
git pull, rm build, reinstall and try the import
Thomas Kluyver
@takluyver
Dec 12 2014 23:18
perhaps there's another copy installed somewhere that it's importing instead of the one you've just installed
epifanio
@epifanio
Dec 12 2014 23:19
i see, i’ll do a locate an check if this is the case
Thomas Kluyver
@takluyver
Dec 12 2014 23:19
try pip uninstall ipython repeatedly until it doesn't find any more
epifanio
@epifanio
Dec 12 2014 23:19
oh, clever :) i’ll do that
thanks!
that was it .. now works fine
epifanio
@epifanio
Dec 12 2014 23:25
can be that jupiter and ipython-dev are overlapping ?
Jason Grout
@jasongrout
Dec 12 2014 23:47
@ellisonbg: is this error better?
/home/ubuntu/bquantvm/pythonpackages/ipython/IPython/html/widgets/__init.py:29: FutureWarning: IPython widgets are experimental and may change in the future.
warn("IPython widgets are experimental and may change in the future.", FutureWarning)
/home/ubuntu/bquant_vm/python_packages/ipython/IPython/html/widgets/__init__.py:29: FutureWarning: IPython widgets are experimental and may change in the future.
  warn("IPython widgets are experimental and may change in the future.", FutureWarning)
it doesn't help you much when you are importing widgets in a library, but it does look maybe a little better from the command line.
or notebook cell