every new shell results in mise-poetry: Virtualenv does not exist at . Execute poetry install to create one.

[simonpercivall]

After #20, I now get warnings every first time I enter a mise-managed directory with poetry or a _.python.venv directive.

I have a venv at .venv next to the pyproject.toml, and that's how poetry is configured. mise also manages the Python install.

The poetry install is defined in a .mise.toml one level up from the pyproject.toml, and the _.python.venv directive is defined in next to the pyproject.toml.

[simonpercivall]

So to me, there are two separate things here:

1. I want to be able to manage a poetry install with mise (for instance, globally) without getting a warning every time I open a shell.
2. I want control over how a virtual env is created or installed when using poetry, without getting warnings in my console.

[simonpercivall]

Ping @chris-lingwood-korelabs-co.

[chris-lingwood-korelabs-co]

I did wonder if I would live to regret that PR....

While we work out in what way this is wrong you can comment out line 17 in ~/.local/share/mise/plugins/poetry/bin/exec-env to stop it being annoying.

Do you have something like this?
poetry = {version='1.8.4', pyproject='pyproject.toml'}
I think I broke the check for pyproject being set which was naive of me.

I'm begining to wonder if the poetry behaviour I saw was a different issue.

[simonpercivall]

:) We all have those PRs.

I don't have the pyproject.toml defined inline, one reason being I want the poetry install managed at the top level of a monorepo.

And thanks for the comment out tip. In case someone else also wants this, and with convenience, this is a quickfix:

sed -i '' 's/echoerr/# echoerr/g' ~/.local/share/mise/plugins/poetry/bin/exec-env

[chris-lingwood-korelabs-co]

Which is fair enough. OK so my issue is that (in a test repo before th venv has been created):

$ poetry env info --path

It just returns nothing with a exit code of 1.

In the code i patched it would just nothing because it checked if the string was empty, which happens for the reasons you have. This broke auto install. Once poetry install is run then poetry env info --path returns the path but manual steps are for chumps ;) It seems like there is something to patch here, just not how I did it.

How about replace:

 if [[ -z "$VIRTUAL_ENV" ]] || [[ ! -d "$VIRTUAL_ENV" ]]; then

with

  pyproject="$(eval "echo ${MISE_TOOL_OPTS__PYPROJECT-}")"
  if [ "$pyproject" != "" ] && ([[ -z "$VIRTUAL_ENV" ]] || [[ ! -d "$VIRTUAL_ENV" ]]); then

It avoids conflating checking the venv location with whether it shoudl be managing the venv at all. That checks for the presence of pyproject= in the toml (which I have and you don't).

[chris-lingwood-korelabs-co]

Nope, scatch that, it ignores another failure mode... (whatever file pyproject points at being missing).

[simonpercivall]

Hmm, unclear if I fully understand. But, perhaps that doesn't matter :)

So, what I wonder is: For your and my needs at least, if MISE_POETRY_AUTO_INSTALL is false, why should that lead to an error being printed? I want to manage it myself, it's not necessarily an error.

I.e.:

diff --git a/bin/exec-env b/bin/exec-env
index 89dca31..b66839e 100755
--- a/bin/exec-env
+++ b/bin/exec-env
@@ -14,7 +14,6 @@ setup_virtualenv() {
   VIRTUAL_ENV="$(poetry_venv)"
   if [[ -z "$VIRTUAL_ENV" ]] || [[ ! -d "$VIRTUAL_ENV" ]]; then
     if [[ "${MISE_POETRY_AUTO_INSTALL:-}" != "true" ]] && [[ "${MISE_POETRY_AUTO_INSTALL:-}" != "1" ]]; then
-      echoerr "mise-poetry: Virtualenv does not exist at $VIRTUAL_ENV. Execute \`poetry install\` to create one."
       return
     fi
     echoerr "mise-poetry: No virtualenv exists. Executing \`poetry install\` to create one."

[chris-lingwood-korelabs-co]

@simonpercivall I've got a pr ready, could you have a go with it and see if it solves your issue? I've handled the various cases a bit better.

I'm a bit reluctant to remove the message just because you shouldn't be hitting it anyway so its not really the bug.