# Managing plugins | DRE

> Plugin packages are installed on demand; how to have them in place before the first run.

You're reading the docs for DRE 0.4 (v0.4.4). [This page for 0.5](https://getdre.com/docs/managing-plugins/) · [New in 0.5](https://getdre.com/docs/new-in-0.5/)

# Managing plugins

However DRE is installed, only `dre` itself is. Every source, format and destination is a plugin package with its own version and releases (`duckdb-v1.0.0`, `xlsx-v1.0.2`, …): `dre init`, `dre run`, `dre validate` and `dre compile` download the ones a project declares, from GitHub Releases, and `dre.lock` pins them (see [the registry docs](https://getdre.com/docs/v0.4/registry/)). A plugin’s version doesn’t follow DRE’s: any DRE runs any plugin release that speaks its [protocol](https://getdre.com/docs/v0.4/protocol/).

To have them in place before the first run, e.g. on a machine or job that starts empty each time:

-   run `dre deps` in the project while building the image, or as its own CI or job step;
-   or point `DRE_PLUGINS_DIR` at a folder that outlives the run (a Databricks Volume, a shared mount, a folder in the image) and run `dre deps` once to fill it.

Downloads (the registry index, plugin packages, `dre system update`) give up on a connection after 30 seconds and on a response that sends nothing for 60, and are tried 3 times, on connection errors, timeouts, 429 and 5xx. There’s no total limit, so a slow but healthy download finishes. On a slow network, raise the 60 seconds with `DRE_HTTP_TIMEOUT` or in `dre_project.yml`:

```yaml
flags:
  http_timeout: 120
```

## Prepare a runner and maintain its pins

The [tutorial project](https://github.com/get-dre/dre/blob/v0.4.4/examples/tutorial/) declares `duckdb`, `csv` and `xlsx`. Install its dependencies during runner setup, then require the run to use those installed versions:

```bash
cd examples/tutorial
dre deps
dre validate --no-auto-install
dre run --no-auto-install --preview 5
dre plugin list
```

`--no-auto-install` prevents an unexpected download in a locked-down runtime. If it reports `plugin-not-installed`, run `dre deps` during setup using the same `DRE_PLUGINS_DIR` as the job. An `undeclared-plugin` instead needs the package added to `dependencies.yml`; installing a binary alone does not declare the dependency.

To try a package explicitly, or move a pin within the project’s version constraint:

```bash
dre plugin install 'xlsx@^1' --project-dir my_reports
dre plugin update xlsx --project-dir my_reports
dre plugin remove xlsx@1.0.2 --project-dir my_reports
```

`install` chooses a requested release; `update` ignores the previous lock pin but obeys the constraint; `remove` deletes installed versions. Remove a version only after no active project uses it. With a shared plugins directory, another project can still need it. Commit the changed `dre.lock` after a deliberate update and validate the report before delivery.

`plugin-install-failed` can mean a network failure, checksum mismatch or unavailable platform build. Read the detailed cause rather than repeatedly loosening a version constraint. See [dependency keys](https://getdre.com/docs/v0.4/reference-dependencies/), the [registry](https://getdre.com/docs/v0.4/registry/), and the [glossary’s plugin package](https://getdre.com/docs/v0.4/glossary/#plugin-package) and [lock file](https://getdre.com/docs/v0.4/glossary/#drelock).

[Previous  
Lookups](https://getdre.com/docs/v0.4/lookups/)[Next  
The manifest and \`run\_results.json\`](https://getdre.com/docs/v0.4/manifest/)