prevents Python discovery without disabling python integration

[gonzad66]

Hi,

When you have an environment with +100 python interpreters (conda envs, venvs, system, modules) python discovery scan all of them as part of the starting step. In our case, it takes around a minute. Moreover, this step is done each time that a positron session is started.

It is possible to prevent the python discovery but allow the user to select the python interpreter only if it will be used in the current session?

Best,

Danilo

[jonvanausdeln]

Thanks for the question, @gonzad66! With 100+ environments, discovery is definitely going to be slow.
There are a few settings that can help you limit what gets scanned without fully disabling Python support. See https://positron.posit.co/python-installations.html#related-settings for the full details, but the key ones are:

• python.interpreters.override - this is probably the most useful for your case. Set it to a list of specific interpreter paths and Positron will only show
  those, skipping the broad discovery scan entirely.
• python.interpreters.exclude - if you'd rather keep discovery but skip certain directories (e.g., a folder with dozens of conda envs you rarely use), you
  can exclude specific paths.
• python.defaultInterpreterPath - sets the default interpreter that Positron will use.

If these don't help, please feel free to file an issue for the feature.

[gonzad66]

Dear @jonvanausdeln,

Thanks for the hints. We had been doing tests by using the described options and it works correctly as individual user. Unfortunately, we are providing positron as part of a shared environment exposed to several users. Thus, this set of solutions will not cover the use case.

Is there any global configuration that we can setup for this?. If not, I will create an issue for such feature.

Best,

Danilo

[juliasilge]

Can you say what you mean by shared environment here? We do provide extensive runtime configuration options for Positron on Workbench:
https://docs.posit.co/ide/server-pro/admin/positron_sessions/interpreter_settings.html

[gonzad66]

Dear @juliasilge ,

Thanks for the feedback. When I mentioned a shared environment is that it is running in such way that is used by multiple users concurrently, each one with their own use case.

About the suggested interpreter settings. Python discovery is running in the background even if I am defining the default python interpreter. And disabling python is not a way to go.

An alternative could be blocking any scanning by default (python.interpreters.exclude), then the users need to setup manually python.interpreters.override to select the interpreters that they wants to use. After that, restart positron.

Maybe enabling an option that prevents the python discovery across the filesystem and let the user focus on the paths that they want to use interactively could be a way to go. For instance, enabling on the interpreter section passing a path argument, then scan this path.

Best,

Danilo

[juliasilge]

I've opened #13136 for us to think through options for a startup strategy in the kind of situation you describe. Please feel free to add any additional info on this!

Currently Python discovery will run in the background, yes, but it should not stop you from getting started on your work, especially once a user has used a Python interpreter for a given workspace.

Moreover, this step is done each time that a positron session is started.

This is true, but it will not block an interpreter starting that you have indicated you want to use. For example, the first time you open a given project/workspace/folder, Positron doesn't yet know what the right Python interpreter is for that workspace. Once you have it open and have chosen an interpreter, that interpreter is then "affiliated" with the workspace and it will start it up immediately, even though discovery is still going on in the background. You can read more here:
https://positron.posit.co/interpreter-startup.html

Also be aware that you can configure any of the python.interpreters settings at the workspace/folder level too (not just the user level). This means that you could set something like this in the workspace-level settings for a given folder and even check that into git with the folder itself:

"python.interpreters.override": [
    "/custom/python/location/3.13.0/bin/python"
]