Provide the prefix of a possibly activated conda environment in getExecutionDetails API

[karrtikr]

Originally posted by @jamilraichouni in #12596 (comment)

Hi!

Would be great if getExecutionDetails were also providing the prefix of a possibly activated conda environment.

That can be identified using the path from execCommand, but then everybody has to do that by his own doing something like

1. Check if environment variable CONDA_PREFIX is set and if not:
2. Check, if there is a conda executable in the same path as the interpreter given in execCommand.

I have a use case where I need to get the conda env prefix during runtime of a conda Python process even if the conda env has not been activated. If there is a more stable way to do that, let me know, please.

Cheers,
Jamil

[jamilraichouni]

Thanks!

Title of issue

Maybe I should have worded it like that and you may want to change the title of the current issue:

„Provide the conda prefix in getExecutionDetails API when the execCommand belongs to a conda environment.“

Example

Something like

getExecutionDetails()["execCommand"] = [
    "/path/to/conda/env/A/bin/python",
    "/path/to/conda/env/B/bin/python",
    "/path/to/system/python"
]
getExecutionDetails()["condaPrefix"] = [
    "/path/to/conda/env/A",
    "/path/to/conda/env/B",
    null
]

Use case

There is a Code extension that maintains website favorites (many of them pointing
to API references/ documentations for Python packages).

Projects often work with different Python environments and Python package versions.
Hence, depending on the selected

• resource (document)
• folder
• workspace

the URL to these Python package documentation websites must be adapted according to the currently selected Python
interpreter.

To do so all website favorites are maintained in a template JSON file.

Cut-out example:

[
    {
        "fallback_url": "https://numpy.org/doc/stable/user",
        "url": "https://numpy.org/doc/${MAJOR}.${MINOR}/user/",
        "pkg_name": "numpy",
        "title": "NumPy ${MAJOR}.${MINOR} (Documentation)"
    },
    {
        "fallback_url": "https://pandas.pydata.org/pandas-docs/stable/",
        "url": "https://pandas.pydata.org/pandas-docs/version/${MAJOR}.${MINOR}.${PATCH}/",
        "pkg_name": "pandas",
        "title": "pandas ${MAJOR}.${MINOR}.${PATCH} (Documentation)"
    }
]

The extension knows some open website command offering all favorites in a
quick pick UI in Code. When the open website command is run, the extension requests the current
interpreter selection via the API of ms-python.python and calls some external
Python tool.

For that call the interpreter from execCommand cannot be used since this tool depends on several packages that are not always given in the selected environment. The interpreter selection in VS Code (execCommand) is passed as argument to that external tool and the tool needs to know the conda prefix but is itself not being run in the conda environment of interest.

Here, the conda environment is not properly activated (env var CONDA_PREFIX is not set).

The external Python tool needs to know the conda prefix of interest but is being run by some default conda interpreter.

During runtime the tool can NOT check for sys.prefix or sys.executable to identify the conda prefix for the selected interpreter.

The prefix is needed to request versions for all Python packages installed in that
conda environment to populate the ${MAJOR}, ${MINOR}, and ${PATCH} placeholders
in the URLs (see example listing above).

When the processing/ filling of placeholders is completed, the quick pick UI is being shown.

That way, the developer can always and very quick choose to open an API reference for any Python
package version corresponding to the resource/ folder/ workspace he/ she is working on.

I can imagine that this is just one out of multiple imaginable use cases.

This is why I request that this additional information will be exposed by the API of the
Python extension.

[jamilraichouni]

I had to rephrase (detail) the use case (see paragraph with bold text above).

[luabud]

Thanks for the suggestion! We talked about it with the team and we have unfortunately decided we will not be moving forward with this idea. We think there isn't an enough widespread need for this to warrant the maintenance cost for the feature.

[jamilraichouni]

Alright, thanks that this has been considered in discussions!