Dependency packages
A dependency package bundles third-party Python libraries for reuse by deployments. Use one when several flows need the same libraries, when imports must be available in managed execution, or when you want to validate dependency compatibility before release.
On this page
Create a packageValidate and buildAttach a completed packageInspect and manage packagesCommon problemsCreating, editing, validating, building, and deleting requires dep_packages.write; reading requires dep_packages.read. Owners, admins, and developers can manage packages, while viewers can inspect them. Full models are in the OpenAPI reference.
Create a package
curl --fail-with-body -X POST "$DAGY_API_URL/dep-packages" \
-H "Authorization: Bearer $DAGY_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name":"Commerce HTTP client",
"description":"Libraries used by order ingestion flows",
"python_version":"3.12",
"dependencies":[{"name":"httpx","version_spec":"==0.28.1"}]
}'The version above is an example pin; choose and test the release your application requires. The 201 response contains package_id, slug, name, Python version, dependencies, validation/build status, and timestamps. Save both identifiers: use package_id for management and the returned slug when attaching it to a deployment.
Supported requested Python versions are 3.10, 3.11, 3.12, and 3.13, with default 3.12. Choose a version compatible with the actual execution runtime; choosing a package version does not change the runtime's interpreter. Creation requires at least one dependency and allows at most 200. Duplicate dependency names are consolidated; supply each intended package once.
Validate and build
- Call
POST /dep-packages/{package_id}/validate. - Inspect
valid,resolved,conflicts, andwarnings. Correct conflicts before release. - Call
POST /dep-packages/{package_id}/build. - Poll
GET /dep-packages/{package_id}untilpackaging_statusisCOMPLETEDorFAILED.
Example successful validation:
{"valid":true,"resolved":["httpx==0.28.1"],"conflicts":null,"warnings":null}Actual resolved output includes transitive dependencies and may contain additional requirements. A build revalidates when the dependency definition changed. Validation failure during build returns 422 with detail.validation_errors.
Build submission returns 202 with message and the updated package. Possible build states include IDLE, QUEUED, INSTALLING, PACKAGING, UPLOADING, COMPLETED, and FAILED. Follow current_dependency, error_message, and build logs for progress. A successful submission does not mean the package is ready.
Validation has a two-minute resolution timeout. A timeout or unavailable build capability needs investigation; repeatedly starting builds will not fix an incompatible dependency set.
Attach a completed package
Use the returned slug in a deployment:
PUT /deployments/orders-develop/settings{"dep_package_slugs":["YOUR_PACKAGE_SLUG"]}Or attach during CLI deploy:
dagy deploy /PATH/TO/artifact.zip --deployment orders-develop \
--dep-packages YOUR_PACKAGE_SLUG --yesThe settings array replaces all current attachments. Send [] to remove them. Use only completed packages, then run a small import/functional check in the selected runtime. Version resolution passing does not guarantee native wheels or system-library compatibility. Runtime support differs; verify the chosen execution mode with your actual dependencies.
Updating dependencies resets validation; it does not rebuild automatically. The package can still show a previous completed build, so explicitly validate and build the changed definition before relying on it. For reproducible releases, create a separate package for a materially different dependency set rather than changing a shared one under several deployments.
Environment promotion does not preserve dependency-package attachments. Reapply the target deployment's slugs after promoting.
Inspect and manage packages
| Operation | Purpose |
|---|---|
GET /dep-packages?limit=50 | List packages in the workspace; no cursor. |
GET /dep-packages/{package_id} | Read definition, status, and error metadata. |
GET /dep-packages/by-slug/{slug} | Resolve a deployment attachment slug. |
PATCH /dep-packages/{package_id} | Change name, description, Python version, or dependencies. |
GET /dep-packages/{package_id}/logs?next_token=… | Read build events and follow the returned continuation token. |
GET /dep-packages/{package_id}/download | Obtain url, filename, and size for a completed package. The signed URL lasts five minutes. |
DELETE /dep-packages/{package_id} | Delete the package and return {"deleted":true}. |
GET /dep-packages/pypi/search?q=httpx | Search package metadata; queries under two characters return no results, up to 20 results otherwise. |
Do not put signed download URLs in long-lived configuration. Request a fresh URL when needed and do not attach the Dagy bearer token when fetching it. Remove deployment references before deleting a package that existing flows use.
Common problems
| Symptom | Resolution |
|---|---|
400 on create/update | Use a supported Python version and no more than 200 dependencies; creation also requires a nonempty set. |
404 resolving a slug | Copy the slug from the package response and confirm the workspace. |
| Validation reports a conflict | Adjust version constraints and inspect the complete conflicts output. |
| Build remains queued | Ask the workspace owner to confirm package-building availability. |
Download returns 400 | Wait for a successful build; an unbuilt package cannot be downloaded. |
| Import fails despite successful validation | Check attachment settings, actual build completion, native dependencies, and runtime compatibility. |
| Promoted flow loses imports | Reattach packages in the destination deployment. |
Dependency packages install Python requirements. They do not automatically package unrelated local source files or provision external databases and services. Use saved connectors for supported connection settings and deployment for flow source.