Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variable Explorer/Viewer #3001

Open
mmagnuski opened this issue Jun 17, 2018 · 7 comments
Open

Variable Explorer/Viewer #3001

mmagnuski opened this issue Jun 17, 2018 · 7 comments
Labels
enhancement jupyter spec pinned workflow: leave issue or pr open (do not close)

Comments

@mmagnuski
Copy link

I know you recently added Data Explorer so I was wondering if you are planning to add also a variable explorer of some sort?
This is the only thing that stops me from teaching python starting with nteract/notebook (currently I will start with Spyder and later move to nteract). I've found in previous courses that for people without any previous coding experience teaching in an environment that displays the state of all variables as they are created and modified helps to build a mental model of namespace/workspace. When I was teaching in notebooks some students would get confused whether given variable is already defined or not (because the cells defining the variable were already there but were not run for example) and whether the order of cells (vs the order of running cells) matter. These problems with constructing the correct mental model of "notebook workspace" evaporate if one is able to track all the variables in some form of variable viewer/explorer (similarily to what is done in spyder).

@rgbkrk
Copy link
Member

rgbkrk commented Jun 19, 2018

I sure wish we had a nice way of doing that.

We're not currently targeting support of it because there is not a non-python specific way of handling this way right now, with the jupyter protocols. Perhaps @Carreau knows where things are at for a variable explorer protocol or where we could take things.

@yozlet
Copy link

yozlet commented Jul 12, 2018

Caveat: I'm a relative newbie, but wanted to do a little research towards helping this happen, so here's what I found in 10 mins:

The Jupyter kernel API used to have a user_variables entry in the execute request/response, and this was for fetching the list of user-created variables in the current execution stack.

Unfortunately for us, 5.0 of the API (a couple of years ago) removed this, and replaced it with user_expressions. This is for holding and executing code in the kernel's own language that will fetch metadata to go alongside the execute output. It's intended for things like custom prompts.

So, the good news is that it's theoretically possible, and there's a place to put it in the protocol. The bad news is that it's language-specific. For each kernel, you'd need an expression in that language to serialise the complete set of user-created variables. But, hey, you'd only need to define that once per kernel, and you'd have some control over the serialisation, so that might make the front-end easier and more powerful.

@mmagnuski
Copy link
Author

I asked that question before knowing about variable explorer project for Jupyterlab (python specific) - now I know about it I think I will teach using jupyterlab. BTW I am not sure if trying to be language-agnostic is a good approach here, as you would like numpy arrays, pandas dataframes etc. to be handled specially and this requires some language specificity in the variable explorer.

@rgbkrk
Copy link
Member

rgbkrk commented Jul 12, 2018

Thanks for outlining that @yozlet!

you'd only need to define that once per kernel, and you'd have some control over the serialisation, so that might make the front-end easier and more powerful.

I'm in agreement there. As long as we do it in a good enough way for Python, R, and Scala, I'm not too worried about making it super generic. I think I'm even ok with something that's Python specific so long as the user_expressions don't cause any side effects.

@yozlet
Copy link

yozlet commented Jul 12, 2018

@mmagnuski Thanks for that, I didn't know about that project. The code is super clean and readable. Here's what I can tell from a brief browse:

  1. It's mostly TypeScript, and it uses JupyterLab's TypeScript APIs to hook into kernel communication
  2. On initial activation, it sets up some custom functions in the kernel's userspace (currently only supporting a few Python kernels) to do inspection & serialization
  3. (I'm unsure about this bit.) Instead of sending user_expression riders along with each execute request, it sends its own execute request as followup.

(This is a really ignorant question, but: Seeing that it's mostly JS underneath, and it's hooking into the increasingly-popular JS API for JupyterLab extensions... could that same API be exposed in nteract? I realise the UI model's mostly different, but maybe the underpinnings are similar enough. I'm saying this with no idea of what nteract's current API is, or what plans for extension support are, so feel free to ignore.)

@stale
Copy link

stale bot commented Oct 14, 2019

This issue hasn't had any activity on it in the last 90 days. Unfortunately we don't get around to dealing with every issue that is opened. Instead of leaving issues open we're seeking to be transparent by closing issues that aren't being prioritized. If no other activity happens on this issue in one week, it will be closed.
It's more than likely that just by me posting about this, the maintainers will take a closer look at these long forgotten issues to help evaluate what to do next.
If you would like to see this issue get prioritized over others, there are multiple avenues 🗓:

  • Ask how you can help with this issue 👩🏿‍💻👨🏻‍💻
  • Help solve other issues the team is currently working on 👨🏾‍💻👩🏼‍💻
  • Donate to nteract so we can support developers to work on these features and bugs more regularly 💰🕐

Thank you!

@stale stale bot added the stale workflow: stale issue label Oct 14, 2019
@rgbkrk rgbkrk added jupyter spec pinned workflow: leave issue or pr open (do not close) labels Nov 3, 2019
@stale stale bot removed the stale workflow: stale issue label Nov 3, 2019
@FernandoChu
Copy link

Hello, is there any update on this? I've seen a recent link that shows that it can be done on jupyterlab here, so I was wondering if something changed and now it can be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement jupyter spec pinned workflow: leave issue or pr open (do not close)
Projects
None yet
Development

No branches or pull requests

5 participants