Poe tries to activate the environment even if poetry config virtualenvs.create false

[lsorber]

When creating a Docker image FROM python:3.8-slim AS base, we set poetry config virtualenvs.create false as the image itself already isolates the Python environment. In that situation, Poe will still try to activate the environment with every task, which works but does generate some unnecessary noise.

Workaround: we currently set ENV POETRY_ACTIVE 1 to avoid the unnecessary activations.

[nat-n]

Hi @lsorber, thanks for the feedback.

By "unnecessary noise" do you just mean that poe invokes poetry run which slows down the process for no benefit? Or is there more to it?

I guess it would not make sense to mediate this with a config on the project itself, for example by setting tool.poe.executor = "simple to never use the poetry venv?

Setting POETRY_ACTIVE will work fine without any side effects as far as poe is concerned, but it is a bit of a hack.

The poetry CLI is kind of slow, so would be too expensive to invoke routinely to check the config. Thus the only way I see to improve would be for the PoetryExecutor to routinely look for and read poetry's config.toml in the platform appropriate location to check if virtualenvs.create is set to false, and if so then it executes the task without any env setup.

Does that sound right to you?

Could a windows dev confirm for me that this would reliably get the correct path for the config on windows?

import os
config_path = f"C:\Users\{os.getlogin()}\AppData\Roaming\pypoetry/config.toml"

[lsorber]

Hi @lsorber, thanks for the feedback.

By "unnecessary noise" do you just mean that poe invokes poetry run which slows down the process for no benefit? Or is there more to it?

Sorry, I should have been more clear:

• Even though there is no environment to activate, running a poe task results in additional output to stdout relating to trying to activate the environment.
• The process of attempting to activate the environment also slows down the execution of the poe task.

To be clear, everything is still perfectly functional without a workaround, it's just that the experience is less than desirable as a result of the above.

I guess it would not make sense to mediate this with a config on the project itself, for example by setting tool.poe.executor = "simple to never use the poetry venv?

That's a great suggestion – however, this would be problematic elsewhere. The trouble with this is that for non-Docker based workflows we actually do want poe to make sure the environment is active, and setting tool.poe.executor = "simple" would prevent that. It's only in a Docker-based workflow where we know with certainty that there is no virtualenv that we would not want poe to try to activate it.

Setting POETRY_ACTIVE will work fine without any side effects as far as poe is concerned, but it is a bit of a hack.

Agreed!

The poetry CLI is kind of slow, so would be too expensive to invoke routinely to check the config. Thus the only way I see to improve would be for the PoetryExecutor to routinely look for and read poetry's config.toml in the platform appropriate location to check if virtualenvs.create is set to false, and if so then it executes the task without any env setup.

Does that sound right to you?

A few comments:

1. I agree that if you can detect if Poetry's virtualenvs.create setting is false that it would make sense to switch to the simple executor.
2. Would it be possible to detect (1) using Poetry as a Python package (if it is available and importable)? That way, you don't need to reimplement Poetry's logic to locate its config files and determine the value of that setting.
3. Poetry may also manage its configuration locally in the project itself if you use the --local option.

Could a windows dev confirm for me that this would reliably get the correct path for the config on windows?

import os
config_path = f"C:\Users\{os.getlogin()}\AppData\Roaming\pypoetry/config.toml"

On Windows, I believe Poetry's global config location is f"{os.environ["APPDATA"]}/pypoetry/auth.toml" ($APPDATA == %AppData% == "C:\Users\%USERNAME%\AppData\Roaming\").

[nat-n]

Hi @lsorber,

I played around a bit with this and came away unconvinced that the complexity of finding and reading the various config files was worth it. It's also quite difficult to write convincing tests for. However I've implemented a more minimal solution that I think should be sufficient for your use case, which is to make poe respect the POETRY_VIRTUALENVS_CREATE env var.

So if you set POETRY_VIRTUALENVS_CREATE=false in your container then poetry will not try to create virtualenvs and poe will not execute tasks via poetry run. And you don't need to set it in the poetry config file.

I hope this works for you.

[lsorber]

That sounds OK to me, thank you for looking into this!

[nat-n]

This feature is available now as of 0.16.1