Per-directory envs

[flying-sheep]

We should have settings like:

{
    // used by language servers
    "hatch.env.default": "default",  // hatch’s `default` env
    // used to map files and subdirectories to envs
    "hatch.env.override": {
        "tests/": "hatch-test.3.13",  // hatch’s default env, e.g. `hatch-test.py3.13` 
        "docs/": "docs",  // custom env for running sphinx
        "*.ipynb": "data-science",  // custom env for running notebooks, with `ipykernel`
    }, 
}

the defaults would probably be

{
    "hatch.env.default": "default",
    "hatch.env.override": {
        "tests/": "hatch-test.*",
    }, 
}

if we want to make globbing envs a thing, but that’s probably hard to determine: would it be the same that hatch test uses?

[karthiknadig]

I would avoid adding settings and let this entirely be provided via hatch config in pyproject.toml, hatch.toml.

That way, you get the same behavior regardless of terminal or this extension.

[flying-sheep]

There are two things I want to do that I can’t do today with the Python extension, which are:

1. Have the type checker use my docs env for files in the docs/ directory (and the standard env for the rest)
2. Run my launch configuration “Build Docs” always with the docs env, never anything else.

Point 1 would be fixed by what I suggest here. Any alternative ideas?

I don’t know how to fix point 2, where should I make an issue for that?

[karthiknadig]

For number 2, that sounds like it should be a Task in task.json. So you can configure it as build task (that can be triggered with ctrl+shift+B) . And you would use something like hatch run in the task the runner. Is this something that could work?

[flying-sheep]

I don’t think tasks can be debugged using VS Code’s debugger UI, or am I wrong?