What pain point is this feature intended to address? Please describe.
Typical jupyter users use a single cell to define all of the imports that they plan to use. Vizier presently requires users to redundantly define 'import's in each cell.
Describe the solution you'd like
The more general solution is in #18 ; We automatically detect symbols representing imports and export them. However, #18 focuses primarily on the python-interpreter. There's also the deeper question of what we do on the back-end. That is, how is an 'import' represented to the Vizier backend.
Describe alternatives you've considered
The current default behavior would be to represent libraries as simple code snippets a'la functions. Those snippets get imported by being executed. However, this approach has several limitations:
It limits our ability to apply library-specific presentation to the user (e.g., #278 )
Treating the import as an opaque code blob forces us to rely on heavyweight mechanisms like parsing and code analysis to do interesting things.
What pain point is this feature intended to address? Please describe. Typical jupyter users use a single cell to define all of the imports that they plan to use. Vizier presently requires users to redundantly define 'import's in each cell.
Describe the solution you'd like The more general solution is in #18 ; We automatically detect symbols representing imports and export them. However, #18 focuses primarily on the python-interpreter. There's also the deeper question of what we do on the back-end. That is, how is an 'import' represented to the Vizier backend.
Describe alternatives you've considered The current default behavior would be to represent libraries as simple code snippets a'la functions. Those snippets get imported by being executed. However, this approach has several limitations:
Additional context Related Tickets:
18
278