`cargo dlx <pkgname> ...` to run packages without installing them

[loynoir]

Problem

There is no builtin support for running a command from a remote cargo package

Proposed Solution

$ cargo dlx --package cowsay@1.6.0 cowsay hello
 _______
< hello >
 -------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
$ ls ~/.cargox/
...

Related FR

• [feat] cargo run --cwd cwd #16116

Notes

npx

Run a command from a local or remote npm package

https://docs.npmjs.com/cli/v11/commands/npx

details

$ npx --yes --package cowsay@1.6.0 cowsay hello
 _______
< hello >
 -------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
$ ls ~/.npm/
_cacache  _logs  _npx  _update-notifier-last-checked

npm exec

https://docs.npmjs.com/cli/v11/commands/npm-exec

details

$ rm -rf ~/.npm \
  && cd `mktemp -d` \
  && npx --help \
  && npm exec --yes --package cowsay@1.6.0 cowsay hello \
  && ls ~/.npm
Run a command from a local or remote npm package

Usage:
npm exec -- <pkg>[@<version>] [args...]
npm exec --package=<pkg>[@<version>] -- <cmd> [args...]
npm exec -c '<cmd> [args...]'
npm exec --package=foo -c '<cmd> [args...]'

Options:
[--package <package-spec> [--package <package-spec> ...]] [-c|--call <call>]
[-w|--workspace <workspace-name> [-w|--workspace <workspace-name> ...]]
[--workspaces] [--include-workspace-root]

alias: x

Run "npm help exec" for more info
 _______
< hello >
 -------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
_cacache  _logs  _npx  _update-notifier-last-checked

yarn dlx

https://yarnpkg.com/cli/dlx

details

$ yarn dlx create-vite

$ yarn dlx -p typescript -p ts-node ts-node --transpile-only -e "console.log('hello!')"

$ yarn dlx -p cowsay@1.6.0 -- cowsay hello
...
 _______
< hello >
 -------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
$ ls ~/.yarn      
berry

pnpm dlx

https://pnpm.io/cli/dlx

details

$ rm -rf ~/.cache/pnpm \
  && pnpm dlx cowsay@1.6.0 hello \
  && ls ~/.cache/pnpm      
Packages: +33
+++++++++++++++++++++++++++++++++
Progress: resolved 33, reused 0, downloaded 33, added 33, done
 _______
< hello >
 -------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
dlx  metadata-v1.3

deno run

https://docs.deno.com/runtime/reference/cli/run/

details

$ deno run --allow-all npm:cowsay@1.6.0 hello
 _______
< hello >
 -------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

bun

Nope.

oven-sh/bun#15427

---

Run a command from remote pypi package

uvx

https://docs.astral.sh/uv/guides/tools/#running-tools

details

$ rm -rf ~/.cache/uv && cd `mktemp -d` && uvx pycowsay@0.0.0.2 hello && ls ~/.cache/uv
...

  -----
< hello >
  -----
   \   ^__^
    \  (oo)\_______
       (__)\       )\/\
           ||----w |
           ||     ||

CACHEDIR.TAG  archive-v0  builds-v0  environments-v2  interpreter-v4  sdists-v9  simple-v18  wheels-v5

[epage]

This would likely be best developed be experimented with as a third-party subcommand to have the flexibility to make breaking changes while working through design decisions, including

• what all sources are allowed for packages and how to handle that on the CLI
• dlx arguments vs arguments to the package
• caching schemes
• garbage collection schemes
• dealing with multiple binaries in a package
• is npm -c really needed
• relative importance of a cargox alias for cargo dlx
• default profile and how to override it
• how much to mirror cargo installs behavior vs do its own thing (e.g. "cargo install" apparently ignores "Cargo.lock" as opposed to "cargo build" #7169)

This will also allow exploring the relative value of such a subcommand to evaluate the worth gained by upstreaming it. We understand that being not being built-in negatively impacts adoption; this was a driving reason for upstreaming rust-script/cargo-script. I'm particularly concerned about usability within the Cargo ecosystem and build times.

As part of this, I'd recommend exploring the decisions made in prior art and their relevance within Cargo.

Another piece of prior art is https://docs.astral.sh/uv/reference/cli/#uv-tool-run

[epage]

Note that for some use cases, people would be better served by #2267 as that will ensure users get the right versions of their tools.

In designing either, we should consider whether the other will happen and how that might affect the design.

[loynoir]

@epage

In designing either, we should consider whether the other will happen and how that might affect the design.

FR links updated.

Beside npx and yarn dlx, also add

• npm exec
• pnpm dlx
• deno run

ensure users get the right versions of their tools

AFAIK

• Most support pkg@version, defaults to pkg means pkg@latest, (while latest means latest at first time calling, I did not test)

• Deno support npm:pkg@version, because deno also support jsr:pkg@version.

[epage]

ensure users get the right versions of their tools

AFAIK

• Most support pkg@version, defaults to pkg means pkg@latest

• Deno support npm:pkg@version, because deno also support jsr:pkg@version.

That requires the user to lookup the version of the tool to match their project. #2267 would have the tool versions kept in Cargo.toml along with the dependencies they are tied to.

[loynoir]

Yes, would be nice to lock integrated tools's latest to Cargo.lock.

But all above impl install under home dir.

It leads me to think.

I think, not same with mentioned run dev-dependencies.

Assume cargo target dir is able to under home dir.

But when git project A and git project B have same bin hello.

Current cargo target dir layout leads to two bin have same output location.

Thus, prove cargo target dir is not able to under home dir.

If cargo target dir is not able to under home dir, there will be build cache performance problem.

[ranger-ross]

For me, I think the value in npx and others is that it gives you a single (and often simpler) command to give to others when trying a new tool or scaffolding a project.
e.g. npx sv create my-app to create a new Svelte app.

Having to ask people first install a cargo-dlx plugin cancels out a lot of that value proposition.
So I can totally see some value with this being a first party Cargo feature in the long run.
That said, I agree its probably better to prototype as a standalone plugin and try to upstream once the design has matured.

---

Also my first impression was that cargo dlx would be roughly equivalent to

cargo install foo
$CARGO_HOME/bin/foo <args>

• It's unclear to me if we should also cargo uninstall foo. For Rust we probably want to keep the compiled bin around since compile times are quiet slow for some of the popular tools.
• If we do reuse $CARGO_HOME/bin
  • how we do handle multiple versions? I think currently the binary is just added to that directory with any kind of version tracking.
  • Do we need to worry about polluting PATH? Maybe better to have a $CARGO_HOME/dlx-bin that is not on the path.

[epage]

Also my first impression was that cargo dlx would be roughly equivalent to

I think it should go in a separate location, subject to the GC

• dlx shouldn't "pollute" the system, ie it shouldn't be observable outside of a cache location
• as you mentioned, cargo install only allows one version at a time.