Feature request: include patchlevel in python venv

[jfly]

Is your feature request related to a problem? Please describe.

At my company, we use poetry and we specify a full python patch version in our pyproject.toml. Example:

$ git grep -A 1 'tool.poetry.dependencies'
pyproject.toml:[tool.poetry.dependencies]
pyproject.toml:python = "3.11.7"

This means that whenever we upgrade Python versions, people need new venvs to get created, or else poetry will start to fail with errors like:

$ poetry install --with dev --sync

Current Python version (3.11.4) is not allowed by the project (3.11.7).
Please change python executable via the "env use" command.

However, direnv currently only creates new venvs when the patch version of python changes, so people have to manually delete the old venv and run direnv reload whenever this happens. direnv's behavior here is intentional (see #1033 and #1035), and apparently has something to do with IDEs like vscode.

Describe the solution you'd like

I'd like direnv to create a new venv whenever the python version changes at all (effectively, the behavior before the change in #1033). To avoid regressing on the vscode experience, I'd propose adding a little more functionality as well:

1. We could create/update a symlink with just the minor version (e.g., python-3.11 -> python-3.11.7).
2. We could add an option to layout_python to pick the level of granularity, or add a new layout_python_full_version with this behavior.

I'd be happy to send in a PR implementing 1) or 2) if you're open to it!

(Also @dne and @offbyone as they both requested the original change.)

[dne]

Option 2 would be fine to me. No idea about the vscode issue, since I don't use it.

I'm wondering why you're not using Poetry's own venv management support over direnv's layout_python though?

[jfly]

We just want to use poetry as a package manager. We use a mix of poetry and pipenv, and it's nice for all venvs to be managed in the same way.

[jfly]

@dne what are your thoughts on option 1? It seems nice to avoid changing the api of the direnv stdlib if possible.

[dne]

@dne what are your thoughts on option 1? It seems nice to avoid changing the api of the direnv stdlib if possible.

I'm not sure how it'd avoid having to start over with a new empty venv, for no reason, when Python is updated to a new fix release (same major/minor version)?

[jfly]

You're right, it would create a brand new, empty venv each time the patch version is changed. That doesn't seem like a big deal to me, but maybe that's because we tightly control the exact version of python we're using on a project by project basis (using asdf). For us, the upgrades are very intentional and we want everyone on the same version of python. It sounds like maybe you're relying upon some floating (system level?) version of python? Then I can see how that would be annoying (system update results in effectively emptying out all your project venvs).

I thought the intent of #1033 was something about vscode (as mentioned in #1035), but now I'm just realizing you haven't said anything about IDEs or vscode in this conversation, haha.