Expose interpreter path using API

[karrtikr]

THIS WILL SOON BE REMOVED. CHECK #12596 FOR THE UPDATED DESIGN PROPOSAL

This code snippet shows how to use the new API, could be helpful.

Update the API as follows by adding a settings section,

interface IExtensionApi {
    /**
     * Promise indicating whether all parts of the extension have completed loading or not.
     * @type {Promise<void>}
     * @memberof IExtensionApi
     */
    ready: Promise<void>;
    debug: {
        /**
         * Generate an array of strings for commands to pass to the Python executable to launch the debugger for remote debugging.
         * Users can append another array of strings of what they want to execute along with relevant arguments to Python.
         * E.g `['/Users/..../pythonVSCode/pythonFiles/ptvsd_launcher.py', '--host', 'localhost', '--port', '57039', '--wait']`
         * @param {string} host
         * @param {number} port
         * @param {boolean} [waitUntilDebuggerAttaches=true]
         * @returns {Promise<string[]>}
         */
        getRemoteLauncherCommand(host: string, port: number, waitUntilDebuggerAttaches: boolean): Promise<string[]>;
    };
    /**
     * Return internal settings within the extension which are stored in VSCode storage
     */
    settings: {
        /**
         * Returns the Python execution command corresponding to the specified resource, taking into account
         * any workspace-specific settings for the workspace to which this resource belongs.
         * E.g of execution commands returned could be,
         * * `['<path to the interpreter set in settings>']`
         * * `['<path to the interpreter selected by the extension when setting is not set>']`
         * * `['conda', 'run', 'python']` which is used to run from within Conda environments.
         * or something similar for some other Python environments.
         * @param {Resource} [resource] A resource for which the setting is asked for.
         * * When no resource is provided, the setting scoped to the first workspace folder is returned.
         * * If no folder is present, it returns the global setting.
         * @returns {(string[] | undefined)} When return value is `undefined`, it means no interpreter is set.
         * Otherwise, join the items returned using space to construct the full execution command.
         */
        getExecutionCommand(resource?: Resource): string[] | undefined;
    };
}

[karrtikr]

formulahendry/vscode-code-runner#604

[karrtikr]

formulahendry/vscode-code-runner#604 (comment):

We've to make sure all these 4 cases work,

1. Old version of Code Runner + Old version of the extension -> already works
2. New version of Code Runner + Old version of the extension
3. New version of Code Runner + New version of the extension
4. Old version of Code Runner + New version of the extension

Proposed changes

Code runner

In the new version of code runner,

We would check if user is using the old or the new python extension using the new setting.

• If he is using the old one, we would look for the settings in the old way
• If he is using the new one, we would look for the settings in the new way using the API
• If new version of code runner is being used, the above proposed changes work fine for cases 2 & 3.

Python extension

• Expose the interpreter path via API. Expose interpreter path using API #11294
• Check if we are using the old version of Code runner or the new one. If using the old one, show a prompt asking user to upgrade Code runner to new version to keep using it. This will solve case 4.

How to check from extension A if user is using the old version of extension B or the new one

Introduce a flag in package.json of both the extensions. Within extension A, check if package.json of extension B has flag set. If it is set, it's the newer version of the extension.

Python extension

• Introduce a feature flag in package.json of the extension, which states if the extension is using the new interpreter storage or not. We're adding the following to our package.json ,

"featureFlags": {
    "usingNewInterpreterStorage": true
}

So you can access the flag using,

const extension = vscode.extensions.getExtension('ms-python.python')!;
const flagValue = extension.packageJSON.featureFlags.usingNewInterpreterStorage;

Code runner

Please add a similar flag in package.json and let us know. You can use the following to call our API, which makes sure the extension is activated before calling the API:

const extension = vscode.extensions.getExtension('ms-python.python')!;
if (!extension.isActive) {
    await extension.activate();
}
const pythonPath = extension.exports.settings.getInterpreterPath(resource);

Note we will have to release Code runnner extension first, followed by the extension release. (which is targeted before May 12)

[DonJayamanne]

  * E.g of execution commands returned could be,
         * * `['<path to the interpreter set in settings>']`
         * * `['<path to the interpreter selected by the extension when setting is not set>']`
         * * `['conda', 'run', 'python']` which is used to run fr

This option will not always work.

• conda run is busted.
  • I didn't think we even used this option
  • Either way it will not work for conda
• Solution won't with pyenv

I"m not convinced we should expose the commands to other extensions.
I believe we should merely expose the executable and be done with it.
That's what was done in the past, extensions accessed pythonPath setting to get the executable.

If we want to own running python code on behalf of other extensions, then we need to provide a method that extensions can call to execute arbitrary python code/files. E.g. execFile or execModule or similar (with options to run in terminal, etc) - now it gets complicated for no real benefit.

In summary my suggestion is just return executable path and be done with it.
Provide old behavior and let external extensions deal with conda, pyenv, pipenv, etc. Or if really important we can own it (but thats bigger).

@luabud @karthiknadig /cc

[karrtikr]

conda run is busted

FYI this is keeping in mind of future that if we ever start using conda run again, we don't have to change the API.

Curious, does running using directly path to interpreter for pyenv doesn't work? Do we always need it to run it within an activated environment?

[brettcannon]

@DonJayamanne

• We know conda run is busted, but we don't want to design ourselves into a corner if it does work someday
• Why won't this work for pyenv? How it is different from any other path that may be provided?

We don't want to own running code for other extensions, we are just exposing how to run code because we and other extensions have a need for this exact functionality. And we are definitely not going to wrap execution APIs as we would then have to mirror all options provided by Node and VS Code and that is not a business we want to be in.