On the theme of making Poe the Poet work well without poetry: in the same way that poe makes it seamless to run tasks for a poetry based project, it could offer similar integrations for project environments managed in other ways, such as with a regular venv. This would require selecting the appropriate implementation of PoeExecutor at runtime.
By default poe should make a good guess about which executor to use, so if the pyproject.toml configures dependencies with poetry then the existing PoetryExecutor would be used as usual. Otherwise it should check if there’s a virtualenv at ./venv or ./.venv, and if so it should use a VirtualenvExecutor, and otherwise fallback to an executor that simply runs the tasks without doing any setup or linking to a specific environment
Of course it should also be possible to explicitly configure when executor should be used, and relevant details such as a relative path to the virtualenv directory.
On the theme of making Poe the Poet work well without poetry: in the same way that poe makes it seamless to run tasks for a poetry based project, it could offer similar integrations for project environments managed in other ways, such as with a regular venv. This would require selecting the appropriate implementation of PoeExecutor at runtime.
By default poe should make a good guess about which executor to use, so if the pyproject.toml configures dependencies with poetry then the existing PoetryExecutor would be used as usual. Otherwise it should check if there’s a virtualenv at
./venv
or./.venv
, and if so it should use a VirtualenvExecutor, and otherwise fallback to an executor that simply runs the tasks without doing any setup or linking to a specific environmentOf course it should also be possible to explicitly configure when executor should be used, and relevant details such as a relative path to the virtualenv directory.