Extension doesn't use selected python interpreter in DevContainer

[nataziel]

I don't think this is specific to developing inside a devcontainer, but vscode setting resolution is quite confusing between user/remote/workspace configuration.

I've got ty-vscode installed within a devcontainer, where I'm developing a project with a standard src type file layout.

The project uses uv to manage the dependencies and venv, but I'm storing the venv outside the project root folder by setting UV_PROJECT_ENVIRONMENT=/root/.cache/uv-venv/venv. When I select that environment as the interpreter in vscode, pylance is able to resolve third party imports just fine.

ty however reports that it is unable to resolve those imports. Setting "ty.interpreter": ["/root/.cache/uv-venv/venv"] in the vscode remote server or workspace settings doesn't seem to make it work even though ty is installed in the project venv as a dev dependency. I've been able to get it to work by specifying environment.python="/root/.cache/uv-venv/venv in pyproject.toml or ty.toml.

From a look around it seems like this might be expected based on a few issues, but figured I'd report anyway:
astral-sh/ty#611
#26
#5
astral-sh/ty#536

Separately I noticed once I got it working I was able to use goto definition on first & third party imports but not stdlib. I think this might be directly related to being in a devcontainer because it's trying to use the vendored stdlib in the binary which probably lives on my host computer filesystem?

For hover it found some information for module imports, but hovering the module when using from syntax shows nothing

import asyncio             # hover asyncio = <module 'asyncio'>
import typing              # hover typing = <module 'typing'>
from typing import cast    # hover typing = null, hover cast = Overload[(typ: @Todo, val: Any) -> _T, (typ: str, val: Any) -> Any, (typ: object, val: Any) -> Any

[MichaReiser]

Thank you. Yes, ty currently doesn't use the environment selected in the IDE as a fallback but we probably should.