8000 Bundle Python with the extension to run under Node (e.g. JavaScript/WebAssembly implementation) · Issue #2375 · microsoft/vscode-python · GitHub 10000
[go: up one dir, main page]

Skip to content
Bundle Python with the extension to run under Node (e.g. JavaScript/WebAssembly implementation) #2375
@ericsnowcurrently

Description

@ericsnowcurrently

Currently the extension relies on whichever Python the user has installed (and selected). This leads to following issues:

  1. any internal Python code in the extension must be compatible with a wide range of Python versions (increasing development/maintenance costs)
  2. internal use of Python means that the user must have at least one Python interpreter installed
  3. there are no guarantees that the user's installed "Python" interpreter is actually one that's compatible with our internal Python code

Thus we should consider bundling a Python interpreter with the extension. The catch is that the bundled interpreter must be cross-platform, or else we must ship one for each platform. Thus we do not have a lot of good options. Our best bet is to use an interpreter that would run under Node.

Possibilities:

Project How
batavia JavaScript interpreter
pypyjs WebAssembly
pyodide WebAssembly
brython JavaScript interpreter
transcrypt Transpiler to JavaScript

Some have also tried compiling Python implementations use emscripten:
micropython, CPython

There's also the option of using a Node "addon". This would allow us to use the normal CPython embedding API to pull Python into Node. However, this has the same problem as distributing a Python binary: not cross-platform.

See this page for a deeper look into possible solutions (for running Python under a JS engine).

I expect that, with the availability of an "embedded" Python, we'd want to re-implement most of the extension in Python (over time, one piece at a time). A concise view of what we'd replace and in what order will help dictate any decision on selecting an embedding solution:

  1. ...
  2. ...

Furthermore, anything we do here would strongly benefit from a clear picture of VS Code's entry points into the extension. From what I understand, that should be covered by:

  • activation mechanism
  • callbacks (e.g. vscode.commands.registerCommand(...))
    • what are all the callbacks we support? (or that we could support?)
  • debugger?
  • language server?
  • ...

It feels like I'm missing something on that list.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-internalLabel for non-user facing issuesfeature-requestRequest for new features or functionalityneeds proposalNeed to make some design decisions

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0