Yes, what you're describing with transparent args sounds very useful and I'd find it handy myself! I'll have to think a bit about how best to go implementing some more.
Re what you're saying whether pypyr is necessarily the best tool for this. . . You make a good point! The simple scripts section in package.json that you can $ npm run <user defined> from the cll are, of course, great for relatively simple commands. . . but they're not really meant for more difficult/complicated workflows - even if you're just doing some non-trivial js transcoding/tree-shaking/asset processing/differential builds/dependency tracking you're likely to use a task-runner like gulp or grunt to do the actual work.
In the case of make, it is an amazing build utility. Because it such a well-built & useful tool it so happens over the years (decades!) people have also been using it as a general purpose automation utility or just as a simple "task runner" with phony targets, which often doesn't really use the actual functionality that makes make great (e.g dependency tracking for quicker rebuilds).
It so happens pypyr exists because over and above the pure "build" functions of a project, for the broader automation functions like packaging & deployment (CD) & devops automation workflows, npm scripts or make are not really meant for this and can lead to frustration when you're trying to start using them as general purpose pipeline or workflow automation tools. pypyr is not at all particularly about tracking dependencies/selective build targets - use make or gulp or similar for that. Instead, a pypyr pipeline might well invoke make or an npm run install to do the building as a first step, let those tools do what they're good at, and then run additional steps to upload the output somewhere, retry web-service calls if they fail, automatically spin up a testing rig somewhere etc.
TOML parsing in general is definitely coming to pypyr (#134) - and I am planning to add a convenience step to read pipeline config from pyproject.toml in a single easy step. That way a pypyr pipeline can consume changeable configuration data that exists in pyproject.toml. This would allow you to use a pypyr pipeline to iterate over & "run as command" strings stored in pyproject.toml.
This is not quite what you're describing, however, because you'd still need a pipeline - although I have half a mind to create a built-in pipeline to do just this - loop over a [tool.pypyr.commands] section in the current directory's pyproject.toml and execute them.
In this case you have
$ pypyr do-pyproject-toml-scripts -- test -v3 -s myproject/tests/test_views.py --pdb
(I'd have to think of a better pipeline name than do-pyproject-toml-scripts 😆 Ideas welcome!)
Since the prospective do-pyproject-toml-scripts pipeline would be built-in to pypyr, you wouldn't have it cluttering up your project directory. Doing it this way would actually be relatively easy for pypyr. Trying to implement it without a pipeline is going to be harder and maybe going against the grain of what pypyr is good at.
Some suggestions:
I'm sure you know about these already, but just for the sake of completeness, I'd feel remiss not to point out some other excellent open-source projects in this arena. . .
You might want to check out tox - this is an amazing tool that not only manages your virtual environments for you, but allows you to specify commands with a "passthrough" argument style like you want! However, tox thinks more in terms of "environments" than "targets", but you could more or less make it behave similarly to the makefile example you gave if you treated each target as an environment in tox.
Since pyproject.toml is relatively new, there is a whole new build ecosystem burgeoning around it - poetry & flit being the obvious examples. These are focused on build, not so much the task-running.
You might want to check out https://github.com/nat-n/poethepoet - I've not used this myself (yet), but it looks like a great project! It does most (or maybe some) of what you're after, especially if you're in the poetry ecosystem already!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4