| Name | ds-run JSON |
| Version |
1.3.0
JSON |
| download |
| home_page | None |
| Summary | run dev scripts |
| upload_time | 2024-08-29 14:52:21 |
| maintainer | None |
| docs_url | None |
| author | None |
| requires_python | >=3.8 |
| license | MIT |
| keywords |
dev
scripts
|
| VCS |
 |
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
No coveralls.
|
# ds: run dev scripts
<!--
[[[cog from cog_helpers import * ]]]
[[[end]]]
-->
<p align="center">
<a href="https://github.com/metaist/ds/actions/workflows/ci.yaml"><img alt="Build" src="https://img.shields.io/github/actions/workflow/status/metaist/ds/.github/workflows/ci.yaml?branch=main&logo=github"/></a>
<a href="https://pypi.org/project/ds-run"><img alt="PyPI" src="https://img.shields.io/pypi/v/ds-run.svg?color=blue" /></a>
<a href="https://pypi.org/project/ds-run"><img alt="Supported Python Versions" src="https://img.shields.io/pypi/pyversions/ds-run" /></a>
</p>
Dev scripts are the short names we give to common tasks and long commands in a software project. `ds` finds and runs dev scripts in your project's configuration file (e.g., `Cargo.toml`, `package.json`, `pyproject.toml`, etc.):
```bash
pip install ds-run # or: uv tool install ds-run
ds --list # list the tasks
ds clean lint test # run multiple tasks
ds format:* # run tasks that match a glob
ds test -vv # pass arguments to tasks
ds -e PORT=8080 run # set environment variables
ds +cspell test # suppress errors
ds -w* build # supports monorepo/workspaces
```
Read more:
- [Installing `ds`](#install)
- [Example configuration files][example-tasks]
- [When should I make a dev script?](#when-should-i-make-a-dev-script)
- [Where should I put my config?](#where-should-i-put-my-config)
- [How does `ds` find my config?](#how-does-ds-find-my-config)
- [Where do tasks run?](#where-do-tasks-run)
## Example
Suppose you want to use `pytest` with `coverage` to run unit tests, doctests, and to generate a branch-level coverage report:
```bash
coverage run --branch --source=src -m \
pytest \
--doctest-modules \
--doctest-ignore-import-errors \
src test;
coverage report -m
```
Instead of typing that, we just add a script to our `pyproject.toml` file:
```toml
[tool.ds.scripts]
test = """
coverage run --branch --source=src -m \
pytest \
--doctest-modules \
--doctest-ignore-import-errors \
src test;
coverage report -m
"""
```
And now you can run it with a quick shorthand:
```bash
ds test
```
## Benefits
♻️ **Works with existing projects**<br />
[Almost](#limitations) a drop-in replacement for:
- **Node** (`package.json`): [`npm run`][npm run], [`yarn run`][yarn run], [`pnpm run`][pnpm run], [`bun run`][bun run]
- **Python** (`pyproject.toml`): [`pdm run`][pdm run], [`rye run`][rye run]
- **PHP** (`composer.json`): [`composer run-script`][composer run-script]
- **Rust** (`Cargo.toml`): [`cargo run-script`][cargo run-script]
**Experimental**: We also support an extremely small subset of the [`Makefile`][#68] format (see [#68]).
See: [Inspirations](#inspirations)
🗂️ **Add monorepo/workspace support anywhere**<br />
Easily [manage monorepos and sub-projects](#workspaces), even if they use different tooling.
🏃 **Run multiple tasks with custom arguments for each task**<br />
Provide [command-line arguments](#command-line-arguments) for multiple tasks as well as simple [argument interpolation](#argument-interpolation).
🪄 **Minimal magic**<br/>
Tries to use familiar syntax and a few clear rules. Checks for basic cycles and raises helpful error messages if things go wrong.
🚀 **Minimal dependencies**<br />
Currently working on removing all of these (see [#46]):
- python (3.8+)
- `tomli` (for python < 3.11)
- `graphlib_backport` (for python < 3.9)
## Limitations
`ds` **does not** strive to be an all-in-one tool for every project and is not a replacement for package management tools or `make`. Here are some things that are not supported or not yet implemented.
- Not Supported: [Lifecycle Events](#not-supported-lifecycle-events)
- Not Supported: [`call` Tasks](#not-supported-call-tasks)
- Partial Support: [`Makefile` format][#68] (see [#68])
- In Progress: [Shell Completions][#44] (see [#44])
- In Progress: [Remove Python Dependency][#46] (see [#46])
## Install
`ds` is typically installed at the system-level to make it available across all your projects.
```bash
python -m pip install ds-run
# or, if you use uv:
uv tool install ds-run
```
You can also [download a Cosmopolitan binary](https://github.com/metaist/ds/releases/latest/download/ds) which runs on Windows, macOS, and Linux:
```bash
export LOCAL_BIN=$HOME/.local/bin # or anywhere on your PATH
mkdir -p $LOCAL_BIN
wget -O $LOCAL_BIN/ds -N https://github.com/metaist/ds/releases/latest/download/ds
chmod +x $LOCAL_BIN/ds
ds --version
# NOTE: it takes a few seconds the first time you run it
```
If you just want to try `ds`:
```bash
uvx --from ds-run ds --version
# or
pipx run ds-run --version
```
## Usage
<!--[[[cog fenced_block(snip_file("src/ds/args.py", beg="Usage:", end="Examples:")) ]]]-->
```text
Usage: ds [--help | --version] [--debug]
[--dry-run]
[--no-config]
[--no-project]
[--list]
[--cwd PATH]
[--file PATH]
[--env-file PATH]
[(--env NAME=VALUE)...]
[--workspace GLOB]...
[--pre][--post]
[<task>...]
Options:
-h, --help
Show this message and exit.
--version
Show program version and exit.
--debug
Show debug messages.
--cwd PATH
Set the starting working directory (default: --file parent).
PATH is resolved relative to the current working directory.
--dry-run
Show which tasks would be run, but don't actually run them.
--env-file PATH
File with environment variables. This file is read before --env
values are applied.
-e NAME=VALUE, --env NAME=VALUE
Set one or more environment variables. Supersedes any values set in
an `--env-file`.
-f PATH, --file PATH
File with task and workspace definitions (default: search in parents).
Read more about the configuration file:
https://github.com/metaist/ds
-l, --list
List available tasks and exit.
--no-config
Do not search for or load a configuration file. Supersedes `--file`.
--no-project
Do not search for project dependencies, e.g., `.venv`, `node_modules`
-w GLOB, --workspace GLOB
Patterns which indicate in which workspaces to run tasks.
GLOB filters the list of workspaces defined in `--file`.
The special pattern '*' matches all of the workspaces.
Read more about configuring workspaces:
https://github.com/metaist/ds#workspaces
--pre, --post
EXPERIMENTAL: Run tasks with pre- and post- names.
<task>
One or more tasks to run with task-specific arguments.
The simplest way to pass arguments to tasks is to put them in quotes:
$ ds 'echo "Hello world"'
For more complex cases you can use a colon (`:`) to indicate start of arguments and double-dash (`--`) to indicate the end:
$ ds echo: "Hello from" -- echo: "the world"
If the first <option> starts with a hyphen (`-`), you may omit the
colon (`:`). If there are no more tasks after the last option, you
may omit the double-dash (`--`).
Tasks are executed in order across any relevant workspaces. If any
task returns a non-zero code, task execution stops unless the
<task> was prefixed with a (`+`) in which case execution continues.
Read more about error suppression:
https://github.com/metaist/ds#error-suppression
```
<!--[[[end]]]-->
## When should I make a dev script?
Typically, you should make a dev script for important steps in your development process. For example, most projects will need a way to run linters and unit tests (see the [`test` example above](#example)). Some projects also need a way to start up a server, fetch configuration files, or clean up generated files.
Dev scripts act as another form of documentation that helps developers understand how to build and work on your project.
## Where should I put my config?
`ds` supports `.json` and `.toml` configuration files (see [examples][example-tasks]) which typically go in the top-level of your project. To avoid making lots of top-level files, `ds` can use common project configuration files.
- **Node**: `package.json` under `scripts`
- **PHP**: `composer.json` under `scripts`
- **Python**: `pyproject.toml` under `[tool.ds.scripts]` (`[tool.pdm.scripts]` and `[tool.rye.scripts]` also supported)
- **Rust**: `Cargo.toml` under `[package.metadata.scripts]` or `[workspace.metadata.scripts]`
- **Other**: `ds.toml` under `[scripts]`
**Experimental**: We support an extremely small subset of the [`Makefile`][#68] format (see [#68]).
Read more:
- [Example configuration files][example-tasks]
- [Workspaces](#workspaces)
## How does `ds` find my config?
If you don't provide a config file using the `--file` option, `ds` will search the current directory and all of its parents for files with these name patterns in the following order:
<!--[[[cog
from ds.parsers import PARSERS
cog.outl()
for key in list(PARSERS):
cog.outl(f"- `{key}`")
cog.outl()
]]] -->
- `ds.toml`
- `pyproject.toml`
- `uv.toml`
- `package.json`
- `Cargo.toml`
- `composer.json`
- `[Mm]akefile`
<!--[[[end]]]-->
If you provide one or more `--workspace` options, the file must contain a [workspace key](#workspaces). Otherwise, then the file must contain a [task key](#task-keys).
If the appropriate key cannot be found, searching continues up the directory tree. The first file that has the appropriate key is used.
One exception to the search process is when using the `--workspace` option: If a workspace member contains a file with the same name as the configuration file, that file is used _within_ the workspace (e.g., a workspace defined in `Cargo.toml` will try to find a `Cargo.toml` in each workspace). Otherwise, the usual search process is used.
## Where do tasks run?
Typically, tasks run in the same directory as the configuration file.
If you provide a `--cwd` option (but not a `--workspace` option), tasks will run in the directory provided by the `--cwd` option.
If you provide one or more `--workspace` options, `--cwd` is ignored and tasks are run in each of the selected workspace members.
**NOTE**: In configuration files, you can use the `cwd` or `working_dir` option to specify a working directory for a _specific_ task and that option will be respected even when using `--workspace` or `--cwd` from the command line.
## Task Keys
`ds` searches configuration files for [tool-specific keys][example-tasks] to find task definitions which should contain a mapping from [task names](#task-names) to [basic tasks](#basic-task) or [composite tasks](#composite-task).
## Task Names
- Task names are strings, that are usually short, lowercase, ASCII letters.
- They can have a colon (`:`) in them, like `py:build`.
- All leading and trailing whitespace in a task name is trimmed.
- If the name is empty or starts with a hash (`#`) it is ignored. This allows formats like `package.json` to "comment out" tasks.
- Don't start a name with a plus (`+`) because that indicates [error suppression](#error-suppression).
- Don't start a name with a hyphen (`-`) because that can make the task look like a [command-line argument](#command-line-arguments).
- Don't end a task name with a colon (`:`) because we use that to pass [command-line arguments](#command-line-arguments)
## Basic Task
A basic task is just a string of what should be executed in a shell using `subprocess.run`.
- Supports most [`pdm`-style][pdm] and [`rye`-style][rye] commands ([except `call`](#not-supported-call-tasks))
- Supports [argument interpolation](#argument-interpolation)
- Supports [error suppression](#error-suppression)
<!--[[[cog insert_file("examples/readme/basic.toml")]]]-->
```toml
# Example: Basic tasks become strings.
[scripts]
ls = "ls -lah"
no_error = "+exit 1" # See "Error Suppression"
# We also support `pdm`-style and `rye`-style commands.
# The following are all equivalent to `ls` above.
ls2 = { cmd = "ls -lah" }
ls3 = { cmd = ["ls", "-lah"] }
ls4 = { shell = "ls -lah" }
```
<!--[[[end]]]-->
## Composite Task
A composite task consists of a series of steps where each step is the name of another task or a shell command.
- Supports [`pdm`-style][pdm] `composite` and [`rye`-style][rye] `chain`
- Supports [argument interpolation](#argument-interpolation)
- Supports [error suppression](#error-suppression)
<!--[[[cog insert_file("examples/readme/composite.toml")]]]-->
```toml
# Example: Composite tasks call other tasks or shell commands.
[scripts]
build = "touch build/$1"
clean = "rm -rf build"
# We also support `pdm`-style and `rye`-style composite commands.
# The following are all equivalent.
all = ["clean", "+mkdir build", "build foo", "build bar", "echo 'Done'"]
pdm-style = { composite = [
"clean",
"+mkdir build", # See: Error Suppression
"build foo",
"build bar",
"echo 'Done'", # Composite tasks can call shell commands.
] }
rye-style = { chain = [
"clean",
"+mkdir build", # See: Error Suppression
"build foo",
"build bar",
"echo 'Done'", # Composite tasks can call shell commands.
] }
```
<!--[[[end]]]-->
## Argument Interpolation
Tasks can include parameters like `$1` and `$2` to indicate that the task accepts arguments.
You can also use `$@` for the "remaining" arguments (i.e. those you haven't yet interpolated yet).
You can also specify a default value for any argument using a `bash`-like syntax: `${1:-default value}`.
Arguments from a [composite task](#composite-task) precede those [from the command-line](#command-line-arguments).
<!--[[[cog insert_file("examples/readme/argument-interpolation.toml")]]]-->
```toml
# Example: Argument interpolation lets you pass arguments to tasks.
[scripts]
# pass arguments, but supply defaults
test = "pytest ${@:-src test}"
# interpolate the first argument (required)
# and then interpolate the remaining arguments, if any
lint = "ruff check $1 ${@:-}"
# we also support the pdm-style {args} placeholder
test2 = "pytest {args:src test}"
lint2 = "ruff check {args}"
# pass an argument and re-use it
release = """\
git commit -am "release: $1";\
git tag $1;\
git push;\
git push --tags;\
git checkout main;\
git merge --no-ff --no-edit prod;\
git push
"""
```
<!--[[[end]]]-->
### Command-line Arguments
When calling `ds` you can specify additional arguments to pass to commands.
```bash
ds build: foo -- build: bar
```
This would run the `build` task first with the argument `foo` and next with the argument `bar`.
A few things to note:
- the colon (`:`) after the task name indicates the start of arguments
- the double dash (`--`) indicates the end of arguments
If the first argument to the task starts with a hyphen, the colon can be omitted.
If there are no more arguments, you can omit the double dash.
```bash
ds test -v
```
If you're not passing arguments, you can put tasks names next to each other:
```bash
ds clean test
```
## Error Suppression
If a task starts with a plus sign (`+`), the plus sign is removed before the command is executed and the command will always produce an return code of `0` (i.e. it will always be considered to have completed successfully).
This is particularly useful in [composite commands](#composite-command) where you want subsequent steps to continue even if a particular step fails. For example:
<!--[[[cog insert_file("examples/readme/error-suppression.toml")]]]-->
```toml
# Example: Error suppression lets subsequent tasks continue after failure.
[scripts]
cspell = "cspell --gitignore '**/*.{py,txt,md,markdown}'"
format = "ruff format ."
die = "+exit 1" # returns error code of 0
die_hard = "exit 2" # returns an error code of 2 unless suppressed elsewhere
lint = ["+cspell", "format"] # format runs even if cspell finds misspellings
```
<!--[[[end]]]-->
Error suppression works both in configuration files and on the command-line:
```bash
ds die_hard format
# => error after `die_hard`
ds +die_hard format
# => no error
```
## Environment Variables
You can set environment variables on a per-task basis:
<!--[[[cog insert_file("examples/readme/environment-variables.toml")]]]-->
```toml
# Example: Environment variables can be set on tasks.
[scripts]
# set an environment variable
run = { cmd = "python -m src.server", env = { FLASK_PORT = "8080" } }
# use a file relative to the configuration file
run2 = { cmd = "python -m src.server", env-file = ".env" }
# composite tasks override environment variables
run3 = { composite = ["run"], env = { FLASK_PORT = "8081" } }
```
<!--[[[end]]]-->
You can also set environment variables on the command-line, but the apply to _all_ of the tasks:
```bash
ds -e FLASK_PORT=8080 run
ds --env-file .env run
```
## Workspaces
Workspaces are a way of managing multiple sub-projects from a top-level. `ds` supports `npm`, `rye`, `uv`, and `Cargo` style workspaces.
When `ds` is called with the `--workspace` option, the configuration file must have one of the [tool-specific workspace keys](https://github.com/metaist/ds/tree/main/examples/workspace).
If no configuration file was provided with the `--file` option, search continues up the directory tree.
**NOTE**: `pnpm` has its own [`pnpm-workspace.yaml`](https://pnpm.io/pnpm-workspace_yaml) format which is not currently supported.
### Workspace Members
The value corresponding to the workspace key should be a list of patterns that indicate which directories (relative to the configuration file) should be included as members. The following `glob`-like patterns are supported:
- `?`: matches a single character (e.g., `ca?` matches `car`, `cab`, and `cat`)
- `[]`: matches specific characters (e.g., `ca[rb]` matches `car` and `cab`)
- `*`: matches multiple characters, but not `/` (e.g., `members/*` matches all the files in `members`, but not further down the tree)
- `**`: matches multiple characters, including `/` (e.g., `members/**` matches all files in `members` and all sub-directories and all of their contents)
If you prefix any pattern with an exclamation point (`!`) then the rest of the pattern describes which files should _not_ be matched.
Patterns are applied in order so subsequent patterns can include or exclude sub-directories as needed. [We also support the `excludes` key](https://github.com/metaist/ds/tree/main/examples/workspace/Cargo.toml) (for `uv` and `Cargo`) which is applied _after_ all the members.
<!--[[[cog insert_file("examples/workspace/ds.toml")]]]-->
```toml
# Example: workspace includes everything in `members` except `members/x`.
[workspace]
members = ["members/*", "!members/x"]
```
<!--[[[end]]]-->
### Workspace Tasks
To run a task across multiple workspaces, use the `--workspace` or `-w` options one or more times with a pattern that indicates where the tasks should run.
For example, consider a workspace with directories `members/a`, `members/b`, and `members/x`. The configuration above would match the first two directories and exclude the third.
The following are all equivalent and run `test` in both `member/a` and `member/b`:
```bash
ds --workspace '*' test # special match that means "all workspaces"
ds -w '*' test # short option
ds -w* test # even shorter option
ds -w '*/a' -w '*/b' test # manually select multiple workspaces
```
## Not Supported: Lifecycle Events
Some task runners (all the `node` ones, `pdm`, `composer`) support running additional pre- and post- tasks when you run a task. However, this obscures the relationship between tasks and can create surprises if you happen to have two tasks with unfortunate names (e.g., `pend` and `prepend`). `ds` does not plan to support this behavior (see [#24]).
As more explicit alternative is to use [composite commands](#composite-command) to clearly describe the relationship between a task and its pre- and post- tasks.
<!--[[[cog insert_file("examples/readme/lifecycle-bad.toml")]]]-->
```toml
# Bad example: hidden assumption that `build` calls `prebuild` first.
[scripts]
prebuild = "echo 'prebuild'"
build = "echo 'build'"
```
<!--[[[end]]]-->
<!--[[[cog insert_file("examples/readme/lifecycle-good.toml")]]]-->
```toml
# Good example: clear relationship between tasks.
[scripts]
prebuild = "echo 'prebuild'"
build = ["prebuild", "echo 'build'"]
```
<!--[[[end]]]-->
## Not Supported: `call` Tasks
Some task runners support special `call` tasks which get converted into language-specific calls. For example, both `pdm` and `rye` can `call` into python packages and `composer` can `call` into a PHP module call.
These types of tasks introduces a significant difference between what you write in the configuration file and what gets executed, so in the interest of reducing magic, `ds` does not currently support this behavior (see [#32]).
A more explicit alternative is to write out the call you intend:
```bash
# {"call": "pkg"} becomes:
python -m pkg
# {"call": "pkg:main('test')"} becomes:
python -c "import sys; from pkg import main as _1; sys.exit(main('test'))"
```
## Inspirations
I've used several task runners, usually as part of build tools. Below is a list of tools used or read about when building `ds`.
- 1976: [`make`][make] (C) - Together with its descendants, `make` is one of the most popular build & task running tools. It is fairly easy to make syntax errors and the tab-based indent drives me up the wall.
- 2000: [`ant`][ant] (Java) - an XML-based replacement for `make`. I actually liked using `ant` quite a bit until I stopped writing Java and didn't want to have `java` as a dependency for my `python` projects.
- 2008: [`gradle`][gradle] (Groovy/Kotlin) - Written for the `jvm`, I pretty much only use this for Android development. Can't say I love it.
- 2010: [`npm`][npm] (JavaScript) - Being able to add a simple `scripts` field to `package.json` made it very easy to run dev scripts. Supports `pre` and `post` lifecycle tasks.
- 2010: [`pdm`][pdm] (Python) - Supports 4 different types of tasks including `cmd`, `shell`, `call`, and `composite`.
- 2012: [`composer`][composer] (PHP) - Uses `composer.json`, similar to `package.json`. Supports pre- and post- task lifecycle for special tasks, command-line arguments, composite tasks, and other options.
- 2016: [`yarn`][yarn] (JavaScript) - An alternative to `npm` which also supports command-line arguments.
- 2016: [`pnpm`][pnpm] (JavaScript) - Another alternative to `npm` which supports many more options including running tasks in parallel.
- 2016: [`just`][just] (Rust) - Defines tasks in a `justfile`, similar to `make`. Supports detecting cycles, running parallel, and many other options.
- 2016: [`cargo-run-script`][cargo-run-script] (Rust) - Uses `Cargo.toml` to configure scripts and supports argument substitution (`$1`, `$2`, etc.).
- 2017: [`cargo-make`][cargo-make] (Rust) - Very extensive port of `make` to Rust defining tasks in `Makefile.toml`.
- 2022: [`hatch`][hatch] (Python) - Defines environment-specific scripts with the ability to suppress errors, like `make`.
- 2023: [`bun`][bun] (Zig) - An alternative to `node` and `npm`.
- 2023: [`rye`][rye] (Rust) - Up-and-coming replacement for managing python projects.
## License
[MIT License](https://github.com/metaist/ds/blob/main/LICENSE.md)
[#24]: https://github.com/metaist/ds/issues/24
[#32]: https://github.com/metaist/ds/issues/32
[#44]: https://github.com/metaist/ds/issues/44
[#46]: https://github.com/metaist/ds/issues/46
[#51]: https://github.com/metaist/ds/issues/51
[#54]: https://github.com/metaist/ds/issues/54
[#68]: https://github.com/metaist/ds/issues/68
[ant]: https://en.wikipedia.org/wiki/Apache_Ant
[bun run]: https://bun.sh/docs/cli/run
[bun]: https://en.wikipedia.org/wiki/Bun_(software)
[cargo run-script]: https://github.com/JoshMcguigan/cargo-run-script/
[cargo-make]: https://github.com/sagiegurari/cargo-make
[cargo-run-script]: https://github.com/JoshMcguigan/cargo-run-script/
[composer run-script]: https://getcomposer.org/doc/articles/scripts.md#running-scripts-manually
[composer]: https://getcomposer.org
[gradle]: https://en.wikipedia.org/wiki/Gradle
[hatch]: https://hatch.pypa.io/1.12/config/environment/overview/#scripts
[just]: https://github.com/casey/just
[make]: https://en.wikipedia.org/wiki/Make_(software)
[npm run]: https://docs.npmjs.com/cli/v10/commands/npm-run-script
[npm]: https://en.wikipedia.org/wiki/Npm
[pdm run]: https://pdm-project.org/latest/usage/scripts/#user-scripts
[pdm]: https://pdm-project.org
[pnpm run]: https://pnpm.io/cli/run
[pnpm]: https://pnpm.io
[rye run]: https://rye.astral.sh/guide/commands/run/
[rye]: https://rye.astral.sh
[yarn run]: https://yarnpkg.com/cli/run
[yarn]: https://yarnpkg.com
[example-tasks]: https://github.com/metaist/ds/tree/main/examples/formats
Raw data
{
"_id": null,
"home_page": null,
"name": "ds-run",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.8",
"maintainer_email": null,
"keywords": "dev, scripts",
"author": null,
"author_email": "Metaist LLC <metaist@metaist.com>",
"download_url": "https://files.pythonhosted.org/packages/8d/e8/4a15940c011412c28e5fff7deb18c9d2585ee3a4634cee05c7cd7117e2cf/ds_run-1.3.0.tar.gz",
"platform": null,
"description": "# ds: run dev scripts\n\n<!--\n[[[cog from cog_helpers import * ]]]\n[[[end]]]\n-->\n<p align=\"center\">\n <a href=\"https://github.com/metaist/ds/actions/workflows/ci.yaml\"><img alt=\"Build\" src=\"https://img.shields.io/github/actions/workflow/status/metaist/ds/.github/workflows/ci.yaml?branch=main&logo=github\"/></a>\n <a href=\"https://pypi.org/project/ds-run\"><img alt=\"PyPI\" src=\"https://img.shields.io/pypi/v/ds-run.svg?color=blue\" /></a>\n <a href=\"https://pypi.org/project/ds-run\"><img alt=\"Supported Python Versions\" src=\"https://img.shields.io/pypi/pyversions/ds-run\" /></a>\n</p>\n\nDev scripts are the short names we give to common tasks and long commands in a software project. `ds` finds and runs dev scripts in your project's configuration file (e.g., `Cargo.toml`, `package.json`, `pyproject.toml`, etc.):\n\n```bash\npip install ds-run # or: uv tool install ds-run\nds --list # list the tasks\nds clean lint test # run multiple tasks\nds format:* # run tasks that match a glob\nds test -vv # pass arguments to tasks\nds -e PORT=8080 run # set environment variables\nds +cspell test # suppress errors\nds -w* build # supports monorepo/workspaces\n```\n\nRead more:\n\n- [Installing `ds`](#install)\n- [Example configuration files][example-tasks]\n- [When should I make a dev script?](#when-should-i-make-a-dev-script)\n- [Where should I put my config?](#where-should-i-put-my-config)\n- [How does `ds` find my config?](#how-does-ds-find-my-config)\n- [Where do tasks run?](#where-do-tasks-run)\n\n## Example\n\nSuppose you want to use `pytest` with `coverage` to run unit tests, doctests, and to generate a branch-level coverage report:\n\n```bash\ncoverage run --branch --source=src -m \\\n pytest \\\n --doctest-modules \\\n --doctest-ignore-import-errors \\\n src test;\ncoverage report -m\n```\n\nInstead of typing that, we just add a script to our `pyproject.toml` file:\n\n```toml\n[tool.ds.scripts]\ntest = \"\"\"\n coverage run --branch --source=src -m \\\n pytest \\\n --doctest-modules \\\n --doctest-ignore-import-errors \\\n src test;\n coverage report -m\n\"\"\"\n```\n\nAnd now you can run it with a quick shorthand:\n\n```bash\nds test\n```\n\n## Benefits\n\n\u267b\ufe0f **Works with existing projects**<br />\n[Almost](#limitations) a drop-in replacement for:\n\n- **Node** (`package.json`): [`npm run`][npm run], [`yarn run`][yarn run], [`pnpm run`][pnpm run], [`bun run`][bun run]\n- **Python** (`pyproject.toml`): [`pdm run`][pdm run], [`rye run`][rye run]\n- **PHP** (`composer.json`): [`composer run-script`][composer run-script]\n- **Rust** (`Cargo.toml`): [`cargo run-script`][cargo run-script]\n\n**Experimental**: We also support an extremely small subset of the [`Makefile`][#68] format (see [#68]).\n\nSee: [Inspirations](#inspirations)\n\n\ud83d\uddc2\ufe0f **Add monorepo/workspace support anywhere**<br />\nEasily [manage monorepos and sub-projects](#workspaces), even if they use different tooling.\n\n\ud83c\udfc3 **Run multiple tasks with custom arguments for each task**<br />\nProvide [command-line arguments](#command-line-arguments) for multiple tasks as well as simple [argument interpolation](#argument-interpolation).\n\n\ud83e\ude84 **Minimal magic**<br/>\nTries to use familiar syntax and a few clear rules. Checks for basic cycles and raises helpful error messages if things go wrong.\n\n\ud83d\ude80 **Minimal dependencies**<br />\nCurrently working on removing all of these (see [#46]):\n\n- python (3.8+)\n- `tomli` (for python < 3.11)\n- `graphlib_backport` (for python < 3.9)\n\n## Limitations\n\n`ds` **does not** strive to be an all-in-one tool for every project and is not a replacement for package management tools or `make`. Here are some things that are not supported or not yet implemented.\n\n- Not Supported: [Lifecycle Events](#not-supported-lifecycle-events)\n- Not Supported: [`call` Tasks](#not-supported-call-tasks)\n- Partial Support: [`Makefile` format][#68] (see [#68])\n- In Progress: [Shell Completions][#44] (see [#44])\n- In Progress: [Remove Python Dependency][#46] (see [#46])\n\n## Install\n\n`ds` is typically installed at the system-level to make it available across all your projects.\n\n```bash\npython -m pip install ds-run\n\n# or, if you use uv:\nuv tool install ds-run\n```\n\nYou can also [download a Cosmopolitan binary](https://github.com/metaist/ds/releases/latest/download/ds) which runs on Windows, macOS, and Linux:\n\n```bash\nexport LOCAL_BIN=$HOME/.local/bin # or anywhere on your PATH\nmkdir -p $LOCAL_BIN\nwget -O $LOCAL_BIN/ds -N https://github.com/metaist/ds/releases/latest/download/ds\nchmod +x $LOCAL_BIN/ds\nds --version\n# NOTE: it takes a few seconds the first time you run it\n```\n\nIf you just want to try `ds`:\n\n```bash\nuvx --from ds-run ds --version\n# or\npipx run ds-run --version\n```\n\n## Usage\n\n<!--[[[cog fenced_block(snip_file(\"src/ds/args.py\", beg=\"Usage:\", end=\"Examples:\")) ]]]-->\n\n```text\nUsage: ds [--help | --version] [--debug]\n [--dry-run]\n [--no-config]\n [--no-project]\n [--list]\n [--cwd PATH]\n [--file PATH]\n [--env-file PATH]\n [(--env NAME=VALUE)...]\n [--workspace GLOB]...\n [--pre][--post]\n [<task>...]\n\nOptions:\n -h, --help\n Show this message and exit.\n\n --version\n Show program version and exit.\n\n --debug\n Show debug messages.\n\n --cwd PATH\n Set the starting working directory (default: --file parent).\n PATH is resolved relative to the current working directory.\n\n --dry-run\n Show which tasks would be run, but don't actually run them.\n\n --env-file PATH\n File with environment variables. This file is read before --env\n values are applied.\n\n -e NAME=VALUE, --env NAME=VALUE\n Set one or more environment variables. Supersedes any values set in\n an `--env-file`.\n\n -f PATH, --file PATH\n File with task and workspace definitions (default: search in parents).\n\n Read more about the configuration file:\n https://github.com/metaist/ds\n\n -l, --list\n List available tasks and exit.\n\n --no-config\n Do not search for or load a configuration file. Supersedes `--file`.\n\n --no-project\n Do not search for project dependencies, e.g., `.venv`, `node_modules`\n\n -w GLOB, --workspace GLOB\n Patterns which indicate in which workspaces to run tasks.\n\n GLOB filters the list of workspaces defined in `--file`.\n The special pattern '*' matches all of the workspaces.\n\n Read more about configuring workspaces:\n https://github.com/metaist/ds#workspaces\n\n --pre, --post\n EXPERIMENTAL: Run tasks with pre- and post- names.\n\n <task>\n One or more tasks to run with task-specific arguments.\n\n The simplest way to pass arguments to tasks is to put them in quotes:\n\n $ ds 'echo \"Hello world\"'\n\n For more complex cases you can use a colon (`:`) to indicate start of arguments and double-dash (`--`) to indicate the end:\n\n $ ds echo: \"Hello from\" -- echo: \"the world\"\n\n If the first <option> starts with a hyphen (`-`), you may omit the\n colon (`:`). If there are no more tasks after the last option, you\n may omit the double-dash (`--`).\n\n Tasks are executed in order across any relevant workspaces. If any\n task returns a non-zero code, task execution stops unless the\n <task> was prefixed with a (`+`) in which case execution continues.\n\n Read more about error suppression:\n https://github.com/metaist/ds#error-suppression\n\n```\n\n<!--[[[end]]]-->\n\n## When should I make a dev script?\n\nTypically, you should make a dev script for important steps in your development process. For example, most projects will need a way to run linters and unit tests (see the [`test` example above](#example)). Some projects also need a way to start up a server, fetch configuration files, or clean up generated files.\n\nDev scripts act as another form of documentation that helps developers understand how to build and work on your project.\n\n## Where should I put my config?\n\n`ds` supports `.json` and `.toml` configuration files (see [examples][example-tasks]) which typically go in the top-level of your project. To avoid making lots of top-level files, `ds` can use common project configuration files.\n\n- **Node**: `package.json` under `scripts`\n- **PHP**: `composer.json` under `scripts`\n- **Python**: `pyproject.toml` under `[tool.ds.scripts]` (`[tool.pdm.scripts]` and `[tool.rye.scripts]` also supported)\n- **Rust**: `Cargo.toml` under `[package.metadata.scripts]` or `[workspace.metadata.scripts]`\n- **Other**: `ds.toml` under `[scripts]`\n\n**Experimental**: We support an extremely small subset of the [`Makefile`][#68] format (see [#68]).\n\nRead more:\n\n- [Example configuration files][example-tasks]\n- [Workspaces](#workspaces)\n\n## How does `ds` find my config?\n\nIf you don't provide a config file using the `--file` option, `ds` will search the current directory and all of its parents for files with these name patterns in the following order:\n\n<!--[[[cog\nfrom ds.parsers import PARSERS\ncog.outl()\nfor key in list(PARSERS):\n cog.outl(f\"- `{key}`\")\ncog.outl()\n]]] -->\n\n- `ds.toml`\n- `pyproject.toml`\n- `uv.toml`\n- `package.json`\n- `Cargo.toml`\n- `composer.json`\n- `[Mm]akefile`\n\n<!--[[[end]]]-->\n\nIf you provide one or more `--workspace` options, the file must contain a [workspace key](#workspaces). Otherwise, then the file must contain a [task key](#task-keys).\n\nIf the appropriate key cannot be found, searching continues up the directory tree. The first file that has the appropriate key is used.\n\nOne exception to the search process is when using the `--workspace` option: If a workspace member contains a file with the same name as the configuration file, that file is used _within_ the workspace (e.g., a workspace defined in `Cargo.toml` will try to find a `Cargo.toml` in each workspace). Otherwise, the usual search process is used.\n\n## Where do tasks run?\n\nTypically, tasks run in the same directory as the configuration file.\n\nIf you provide a `--cwd` option (but not a `--workspace` option), tasks will run in the directory provided by the `--cwd` option.\n\nIf you provide one or more `--workspace` options, `--cwd` is ignored and tasks are run in each of the selected workspace members.\n\n**NOTE**: In configuration files, you can use the `cwd` or `working_dir` option to specify a working directory for a _specific_ task and that option will be respected even when using `--workspace` or `--cwd` from the command line.\n\n## Task Keys\n\n`ds` searches configuration files for [tool-specific keys][example-tasks] to find task definitions which should contain a mapping from [task names](#task-names) to [basic tasks](#basic-task) or [composite tasks](#composite-task).\n\n## Task Names\n\n- Task names are strings, that are usually short, lowercase, ASCII letters.\n- They can have a colon (`:`) in them, like `py:build`.\n- All leading and trailing whitespace in a task name is trimmed.\n- If the name is empty or starts with a hash (`#`) it is ignored. This allows formats like `package.json` to \"comment out\" tasks.\n- Don't start a name with a plus (`+`) because that indicates [error suppression](#error-suppression).\n- Don't start a name with a hyphen (`-`) because that can make the task look like a [command-line argument](#command-line-arguments).\n- Don't end a task name with a colon (`:`) because we use that to pass [command-line arguments](#command-line-arguments)\n\n## Basic Task\n\nA basic task is just a string of what should be executed in a shell using `subprocess.run`.\n\n- Supports most [`pdm`-style][pdm] and [`rye`-style][rye] commands ([except `call`](#not-supported-call-tasks))\n- Supports [argument interpolation](#argument-interpolation)\n- Supports [error suppression](#error-suppression)\n\n<!--[[[cog insert_file(\"examples/readme/basic.toml\")]]]-->\n\n```toml\n# Example: Basic tasks become strings.\n\n[scripts]\nls = \"ls -lah\"\nno_error = \"+exit 1\" # See \"Error Suppression\"\n\n# We also support `pdm`-style and `rye`-style commands.\n# The following are all equivalent to `ls` above.\nls2 = { cmd = \"ls -lah\" }\nls3 = { cmd = [\"ls\", \"-lah\"] }\nls4 = { shell = \"ls -lah\" }\n```\n\n<!--[[[end]]]-->\n\n## Composite Task\n\nA composite task consists of a series of steps where each step is the name of another task or a shell command.\n\n- Supports [`pdm`-style][pdm] `composite` and [`rye`-style][rye] `chain`\n- Supports [argument interpolation](#argument-interpolation)\n- Supports [error suppression](#error-suppression)\n\n<!--[[[cog insert_file(\"examples/readme/composite.toml\")]]]-->\n\n```toml\n# Example: Composite tasks call other tasks or shell commands.\n\n[scripts]\nbuild = \"touch build/$1\"\nclean = \"rm -rf build\"\n\n# We also support `pdm`-style and `rye`-style composite commands.\n# The following are all equivalent.\nall = [\"clean\", \"+mkdir build\", \"build foo\", \"build bar\", \"echo 'Done'\"]\n\npdm-style = { composite = [\n \"clean\",\n \"+mkdir build\", # See: Error Suppression\n \"build foo\",\n \"build bar\",\n \"echo 'Done'\", # Composite tasks can call shell commands.\n] }\n\nrye-style = { chain = [\n \"clean\",\n \"+mkdir build\", # See: Error Suppression\n \"build foo\",\n \"build bar\",\n \"echo 'Done'\", # Composite tasks can call shell commands.\n] }\n```\n\n<!--[[[end]]]-->\n\n## Argument Interpolation\n\nTasks can include parameters like `$1` and `$2` to indicate that the task accepts arguments.\n\nYou can also use `$@` for the \"remaining\" arguments (i.e. those you haven't yet interpolated yet).\n\nYou can also specify a default value for any argument using a `bash`-like syntax: `${1:-default value}`.\n\nArguments from a [composite task](#composite-task) precede those [from the command-line](#command-line-arguments).\n\n<!--[[[cog insert_file(\"examples/readme/argument-interpolation.toml\")]]]-->\n\n```toml\n# Example: Argument interpolation lets you pass arguments to tasks.\n\n[scripts]\n# pass arguments, but supply defaults\ntest = \"pytest ${@:-src test}\"\n\n# interpolate the first argument (required)\n# and then interpolate the remaining arguments, if any\nlint = \"ruff check $1 ${@:-}\"\n\n# we also support the pdm-style {args} placeholder\ntest2 = \"pytest {args:src test}\"\nlint2 = \"ruff check {args}\"\n\n# pass an argument and re-use it\nrelease = \"\"\"\\\n git commit -am \"release: $1\";\\\n git tag $1;\\\n git push;\\\n git push --tags;\\\n git checkout main;\\\n git merge --no-ff --no-edit prod;\\\n git push\n\"\"\"\n```\n\n<!--[[[end]]]-->\n\n### Command-line Arguments\n\nWhen calling `ds` you can specify additional arguments to pass to commands.\n\n```bash\nds build: foo -- build: bar\n```\n\nThis would run the `build` task first with the argument `foo` and next with the argument `bar`.\n\nA few things to note:\n\n- the colon (`:`) after the task name indicates the start of arguments\n- the double dash (`--`) indicates the end of arguments\n\nIf the first argument to the task starts with a hyphen, the colon can be omitted.\nIf there are no more arguments, you can omit the double dash.\n\n```bash\nds test -v\n```\n\nIf you're not passing arguments, you can put tasks names next to each other:\n\n```bash\nds clean test\n```\n\n## Error Suppression\n\nIf a task starts with a plus sign (`+`), the plus sign is removed before the command is executed and the command will always produce an return code of `0` (i.e. it will always be considered to have completed successfully).\n\nThis is particularly useful in [composite commands](#composite-command) where you want subsequent steps to continue even if a particular step fails. For example:\n\n<!--[[[cog insert_file(\"examples/readme/error-suppression.toml\")]]]-->\n\n```toml\n# Example: Error suppression lets subsequent tasks continue after failure.\n\n[scripts]\ncspell = \"cspell --gitignore '**/*.{py,txt,md,markdown}'\"\nformat = \"ruff format .\"\ndie = \"+exit 1\" # returns error code of 0\ndie_hard = \"exit 2\" # returns an error code of 2 unless suppressed elsewhere\nlint = [\"+cspell\", \"format\"] # format runs even if cspell finds misspellings\n```\n\n<!--[[[end]]]-->\n\nError suppression works both in configuration files and on the command-line:\n\n```bash\nds die_hard format\n# => error after `die_hard`\n\nds +die_hard format\n# => no error\n```\n\n## Environment Variables\n\nYou can set environment variables on a per-task basis:\n\n<!--[[[cog insert_file(\"examples/readme/environment-variables.toml\")]]]-->\n\n```toml\n# Example: Environment variables can be set on tasks.\n\n[scripts]\n# set an environment variable\nrun = { cmd = \"python -m src.server\", env = { FLASK_PORT = \"8080\" } }\n\n# use a file relative to the configuration file\nrun2 = { cmd = \"python -m src.server\", env-file = \".env\" }\n\n# composite tasks override environment variables\nrun3 = { composite = [\"run\"], env = { FLASK_PORT = \"8081\" } }\n```\n\n<!--[[[end]]]-->\n\nYou can also set environment variables on the command-line, but the apply to _all_ of the tasks:\n\n```bash\nds -e FLASK_PORT=8080 run\nds --env-file .env run\n```\n\n## Workspaces\n\nWorkspaces are a way of managing multiple sub-projects from a top-level. `ds` supports `npm`, `rye`, `uv`, and `Cargo` style workspaces.\n\nWhen `ds` is called with the `--workspace` option, the configuration file must have one of the [tool-specific workspace keys](https://github.com/metaist/ds/tree/main/examples/workspace).\n\nIf no configuration file was provided with the `--file` option, search continues up the directory tree.\n\n**NOTE**: `pnpm` has its own [`pnpm-workspace.yaml`](https://pnpm.io/pnpm-workspace_yaml) format which is not currently supported.\n\n### Workspace Members\n\nThe value corresponding to the workspace key should be a list of patterns that indicate which directories (relative to the configuration file) should be included as members. The following `glob`-like patterns are supported:\n\n- `?`: matches a single character (e.g., `ca?` matches `car`, `cab`, and `cat`)\n- `[]`: matches specific characters (e.g., `ca[rb]` matches `car` and `cab`)\n- `*`: matches multiple characters, but not `/` (e.g., `members/*` matches all the files in `members`, but not further down the tree)\n- `**`: matches multiple characters, including `/` (e.g., `members/**` matches all files in `members` and all sub-directories and all of their contents)\n\nIf you prefix any pattern with an exclamation point (`!`) then the rest of the pattern describes which files should _not_ be matched.\n\nPatterns are applied in order so subsequent patterns can include or exclude sub-directories as needed. [We also support the `excludes` key](https://github.com/metaist/ds/tree/main/examples/workspace/Cargo.toml) (for `uv` and `Cargo`) which is applied _after_ all the members.\n\n<!--[[[cog insert_file(\"examples/workspace/ds.toml\")]]]-->\n\n```toml\n# Example: workspace includes everything in `members` except `members/x`.\n\n[workspace]\nmembers = [\"members/*\", \"!members/x\"]\n```\n\n<!--[[[end]]]-->\n\n### Workspace Tasks\n\nTo run a task across multiple workspaces, use the `--workspace` or `-w` options one or more times with a pattern that indicates where the tasks should run.\n\nFor example, consider a workspace with directories `members/a`, `members/b`, and `members/x`. The configuration above would match the first two directories and exclude the third.\n\nThe following are all equivalent and run `test` in both `member/a` and `member/b`:\n\n```bash\nds --workspace '*' test # special match that means \"all workspaces\"\nds -w '*' test # short option\nds -w* test # even shorter option\nds -w '*/a' -w '*/b' test # manually select multiple workspaces\n```\n\n## Not Supported: Lifecycle Events\n\nSome task runners (all the `node` ones, `pdm`, `composer`) support running additional pre- and post- tasks when you run a task. However, this obscures the relationship between tasks and can create surprises if you happen to have two tasks with unfortunate names (e.g., `pend` and `prepend`). `ds` does not plan to support this behavior (see [#24]).\n\nAs more explicit alternative is to use [composite commands](#composite-command) to clearly describe the relationship between a task and its pre- and post- tasks.\n\n<!--[[[cog insert_file(\"examples/readme/lifecycle-bad.toml\")]]]-->\n\n```toml\n# Bad example: hidden assumption that `build` calls `prebuild` first.\n[scripts]\nprebuild = \"echo 'prebuild'\"\nbuild = \"echo 'build'\"\n```\n\n<!--[[[end]]]-->\n\n<!--[[[cog insert_file(\"examples/readme/lifecycle-good.toml\")]]]-->\n\n```toml\n# Good example: clear relationship between tasks.\n[scripts]\nprebuild = \"echo 'prebuild'\"\nbuild = [\"prebuild\", \"echo 'build'\"]\n```\n\n<!--[[[end]]]-->\n\n## Not Supported: `call` Tasks\n\nSome task runners support special `call` tasks which get converted into language-specific calls. For example, both `pdm` and `rye` can `call` into python packages and `composer` can `call` into a PHP module call.\n\nThese types of tasks introduces a significant difference between what you write in the configuration file and what gets executed, so in the interest of reducing magic, `ds` does not currently support this behavior (see [#32]).\n\nA more explicit alternative is to write out the call you intend:\n\n```bash\n# {\"call\": \"pkg\"} becomes:\npython -m pkg\n\n# {\"call\": \"pkg:main('test')\"} becomes:\npython -c \"import sys; from pkg import main as _1; sys.exit(main('test'))\"\n```\n\n## Inspirations\n\nI've used several task runners, usually as part of build tools. Below is a list of tools used or read about when building `ds`.\n\n- 1976: [`make`][make] (C) - Together with its descendants, `make` is one of the most popular build & task running tools. It is fairly easy to make syntax errors and the tab-based indent drives me up the wall.\n\n- 2000: [`ant`][ant] (Java) - an XML-based replacement for `make`. I actually liked using `ant` quite a bit until I stopped writing Java and didn't want to have `java` as a dependency for my `python` projects.\n\n- 2008: [`gradle`][gradle] (Groovy/Kotlin) - Written for the `jvm`, I pretty much only use this for Android development. Can't say I love it.\n\n- 2010: [`npm`][npm] (JavaScript) - Being able to add a simple `scripts` field to `package.json` made it very easy to run dev scripts. Supports `pre` and `post` lifecycle tasks.\n\n- 2010: [`pdm`][pdm] (Python) - Supports 4 different types of tasks including `cmd`, `shell`, `call`, and `composite`.\n\n- 2012: [`composer`][composer] (PHP) - Uses `composer.json`, similar to `package.json`. Supports pre- and post- task lifecycle for special tasks, command-line arguments, composite tasks, and other options.\n\n- 2016: [`yarn`][yarn] (JavaScript) - An alternative to `npm` which also supports command-line arguments.\n\n- 2016: [`pnpm`][pnpm] (JavaScript) - Another alternative to `npm` which supports many more options including running tasks in parallel.\n\n- 2016: [`just`][just] (Rust) - Defines tasks in a `justfile`, similar to `make`. Supports detecting cycles, running parallel, and many other options.\n\n- 2016: [`cargo-run-script`][cargo-run-script] (Rust) - Uses `Cargo.toml` to configure scripts and supports argument substitution (`$1`, `$2`, etc.).\n\n- 2017: [`cargo-make`][cargo-make] (Rust) - Very extensive port of `make` to Rust defining tasks in `Makefile.toml`.\n\n- 2022: [`hatch`][hatch] (Python) - Defines environment-specific scripts with the ability to suppress errors, like `make`.\n\n- 2023: [`bun`][bun] (Zig) - An alternative to `node` and `npm`.\n\n- 2023: [`rye`][rye] (Rust) - Up-and-coming replacement for managing python projects.\n\n## License\n\n[MIT License](https://github.com/metaist/ds/blob/main/LICENSE.md)\n\n[#24]: https://github.com/metaist/ds/issues/24\n[#32]: https://github.com/metaist/ds/issues/32\n[#44]: https://github.com/metaist/ds/issues/44\n[#46]: https://github.com/metaist/ds/issues/46\n[#51]: https://github.com/metaist/ds/issues/51\n[#54]: https://github.com/metaist/ds/issues/54\n[#68]: https://github.com/metaist/ds/issues/68\n[ant]: https://en.wikipedia.org/wiki/Apache_Ant\n[bun run]: https://bun.sh/docs/cli/run\n[bun]: https://en.wikipedia.org/wiki/Bun_(software)\n[cargo run-script]: https://github.com/JoshMcguigan/cargo-run-script/\n[cargo-make]: https://github.com/sagiegurari/cargo-make\n[cargo-run-script]: https://github.com/JoshMcguigan/cargo-run-script/\n[composer run-script]: https://getcomposer.org/doc/articles/scripts.md#running-scripts-manually\n[composer]: https://getcomposer.org\n[gradle]: https://en.wikipedia.org/wiki/Gradle\n[hatch]: https://hatch.pypa.io/1.12/config/environment/overview/#scripts\n[just]: https://github.com/casey/just\n[make]: https://en.wikipedia.org/wiki/Make_(software)\n[npm run]: https://docs.npmjs.com/cli/v10/commands/npm-run-script\n[npm]: https://en.wikipedia.org/wiki/Npm\n[pdm run]: https://pdm-project.org/latest/usage/scripts/#user-scripts\n[pdm]: https://pdm-project.org\n[pnpm run]: https://pnpm.io/cli/run\n[pnpm]: https://pnpm.io\n[rye run]: https://rye.astral.sh/guide/commands/run/\n[rye]: https://rye.astral.sh\n[yarn run]: https://yarnpkg.com/cli/run\n[yarn]: https://yarnpkg.com\n[example-tasks]: https://github.com/metaist/ds/tree/main/examples/formats\n",
"bugtrack_url": null,
"license": "MIT",
"summary": "run dev scripts",
"version": "1.3.0",
"project_urls": {
"Changelog": "https://github.com/metaist/ds/blob/main/CHANGELOG.md",
"Documentation": "https://metaist.github.io/ds/",
"Homepage": "https://github.com/metaist/ds",
"Repository": "https://github.com/metaist/ds.git"
},
"split_keywords": [
"dev",
" scripts"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "eaa36b17b48eb22f4bce4e7c626c8e214c7ab008cea9e44637890d11780e9b8d",
"md5": "70168660264e9eb35f4fbf9793704a8f",
"sha256": "9e2f6c9aeed46da347bf7146ac161b8e6b0638fe14d080a1fed0b688e7286d72"
},
"downloads": -1,
"filename": "ds_run-1.3.0-py3-none-any.whl",
"has_sig": false,
"md5_digest": "70168660264e9eb35f4fbf9793704a8f",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.8",
"size": 43998,
"upload_time": "2024-08-29T14:52:19",
"upload_time_iso_8601": "2024-08-29T14:52:19.866309Z",
"url": "https://files.pythonhosted.org/packages/ea/a3/6b17b48eb22f4bce4e7c626c8e214c7ab008cea9e44637890d11780e9b8d/ds_run-1.3.0-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "8de84a15940c011412c28e5fff7deb18c9d2585ee3a4634cee05c7cd7117e2cf",
"md5": "dca389fb9a9905e7f3bbc1b6a3e8f353",
"sha256": "11d7f6702017c92fe8a4828ddb9cc1627a8f6b27ef30ae1db9336c0026c56cb5"
},
"downloads": -1,
"filename": "ds_run-1.3.0.tar.gz",
"has_sig": false,
"md5_digest": "dca389fb9a9905e7f3bbc1b6a3e8f353",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.8",
"size": 48800,
"upload_time": "2024-08-29T14:52:21",
"upload_time_iso_8601": "2024-08-29T14:52:21.559700Z",
"url": "https://files.pythonhosted.org/packages/8d/e8/4a15940c011412c28e5fff7deb18c9d2585ee3a4634cee05c7cd7117e2cf/ds_run-1.3.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-08-29 14:52:21",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "metaist",
"github_project": "ds",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"lcname": "ds-run"
}
