I’m the author of Poe the Poet which aims to solve part of this problem; managing “scripts” or “tasks” defined in pyproject.toml as commands or references to python functions, and running them in the appropriate environment.
As @bernatgabor noted, I can’t imagine a single configuration schema that would fit comfortably with many different tools in this space beyond basic use cases.
But what I do find quite interesting is the idea of a standard way to declare which tool should be used to run common tasks (as least in their canonical form), and an interface specification for how the task runner and environment manager components can be programatically invoked to work together.
I think this would address part of the core problem that initially motivated my work (and a few similar projects) in this area, i.e. providing a convenient way to manage and run dev tasks in poetry projects, where the default solution would usually otherwise be a Makefile with calls to poetry run.
For illustrative purposes I imagine something along the lines of the following:
[project.tasks]
requires = ["poetry", "poethepoet"]
runner = "poethepoet.runner:main"
env = "poetry.env_provider:main"
tasks = ["test", "lint", "format", "build"]
where:
- env_provider conforms to
env_provider(project_dir: str) -> EnvDetails - taskrunner conforms to
taskrunner(project_dir: str, env: EnvDetails, task_name: str) - EnvDetails is a path or whatever works best for identifying a virtualenv or base_prefix to use.
This would make it possible for any CI tool, IDE plugin, or other script to check which tasks are implemented for the project, activate the required environment, and run the tasks.
It would also allow users to mix and match tools for defining their dev/prod requirements (e.g. poetry or pipenv, tox) with tools for running their dev tasks (e.g. poethepoet, invoke, tox).
Maybe it would make sense to also pass a dictionary of options for the task, though I’m not sure how easy this would be to standardise across task runners.
Am I on topic?