-
Notifications
You must be signed in to change notification settings - Fork 996
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Task runner plugin system #10211
Comments
Although the expected format is different, does this issue(#5903) function as you expected? |
Interesting, this sounds like an implementation of #5903 that just invokes a third-party tool? Sort of a plugin system? |
@zanieb I think it could function that way. Put another way, I'm proposing that UV provide a command for projects to alias in whatever way they might want. Taking the initial taskipy example from #5903 you could configure: [dependency-groups]
dev = ["taskipy"]
[tool.uv.do]
command = "uv run task"
[tool.taskipy.tasks]
hello = "echo Hello from taskipy!" Any then run:
I see two main advantages of this approach has over #5903:
|
One downside of this proposal vs #5903 is that new contributors to a project that uses UV won't always be able to look for the same |
In my projects that use
uv
I've developed a pattern (which I've encoded in a template repo) where I define a script calleddev.py
that usesclick
to define a CLI and automate common tasks (e.g. running tests, building docs and linting). With that in mind it would be nice if it were possible to define a "default script" so that, instead of typinguv run dev.py ...
, I could avoid typingdev.py
each time and use a shorter command a layarn run
ornpm run
which inherit commands from thescripts
section ofpackage.json
. Sinceuv run
wouldn't be suitable for this due to the fact that positional arguments would be confused with executables, an alternative command likeuv do ...
would be necessary. A hypothetical configuration could look something like:I understand this might be considered relatively niche, however I could imagine a feature like this negating the need for UV to develop it's own system for defining and executing "user scripts" as other package managers in the Python space have (e.g. Hatch's and PDM's approaches). Instead, UV could defer to existing tools in the Python ecosystem for this like Nox or Invoke.
The text was updated successfully, but these errors were encountered: