Skip to content

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

Closed

Description

@karrtikr

Originally posted by Jamil RAICHOUNI (@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

Activity

  1. ghost added
    triage-neededNeeds assignment to the proper sub-team
    on Jul 19, 2020
  2. jamilraichouni commented on Jul 19, 2020

    @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.

  3. jamilraichouni commented on Jul 19, 2020

    @jamilraichouni

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

  4. ghost removed
    triage-neededNeeds assignment to the proper sub-team
    on Jul 20, 2020
  5. luabud commented on Sep 9, 2020

    @luabud
    Member

    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.

  6. jamilraichouni commented on Sep 9, 2020

    @jamilraichouni

    Alright, thanks that this has been considered in discussions!

  7. locked as resolved and limited conversation to collaborators on Oct 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature-requestRequest for new features or functionality

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions