investigate relative imports. about ipynb HOT 4 OPEN

I played around with this. If you can get __package__ to be 'ipynb.fs' and have ipynb.fs imported, then you can just do from .somenotebook import X and it'll work same as from ipynb.fs.somenotebook import X. We could possibly do this for notebooks with an ipython extension of some sort?

from ipynb.

Right now, I tested this by having two files:

wat/say.ipynb:

def say(what):
    print(what)

wat/init.ipynb

from .say import say
__all__ = [say]

Now, from outside, I could do this:

from wat import say
say('hello world')

That calls the correct function, and works!

So this works from the outside. However, if I try to execute wat/init.ipynb in the notebook interface, I get the following error on import:

SystemError: Parent module '' not loaded, cannot perform relative import

if I run:

__package__ = 'ipynb.fs.wat'

before importing, it gets to:

SystemError: Parent module 'ipynb.fs.wat' not loaded, cannot perform relative import

Which is better. if I do a:

import ipynb.fs.wat

in init.ipynb it succeeds (weird!) and then if I try to relative import again I get:

ImportError: No module named 'ipynb.fs.wat.Untitled'; 'ipynb.fs.wat' is not a package

Curious and needs more investigation :D

from ipynb.

So I did a bunch of work here, and it kinda works.

In test.ipynb:

def say(what):
    print(what)

In client.ipynb:

__package__ = 'ipynb.fs'
import ipynb.fs
from .test import say

say("hello world")

This works. The first two lines in the client are the boilerplate. We might be able to automate that with some ipynb extension setup maybe?

Note that this totally works when you're calling it from python directly or with python -m.

from ipynb.

Funkier than expected. Right now, if notebook A imports notebook B as:

from ipynb.fs.full.notebookB import foo

and then notebook B imports notebook C as

import ipynb.fs
from .defs.notebookC import bar

The transient import will fail, since the package for notebookB will already be ipynb.fs.full.notebookB.

The underlying core problem is:

• Python doesn't set package for interactive usage at all, so relative imports currently don't work in notebook at all. So we're trying to add additional semantics there, and this causes confusion.
• We want the code to work the same when imported as a module and when run interactively. These need to be accomplished via separate mechanisms, and they must be kept in sync.

It looks like we might need to do AST munging to make this happen. We just munge AST to resolve the relative imports ourselves.

from ipynb.