Skip to content

Commit

Permalink
Update project-dependencies.md (#4247)
Browse files Browse the repository at this point in the history
## What are you changing in this pull request and why?
We don't allow private packages via Git Token to be defined in the
`dependencies.yml` file so we should call it out for clarity.

dbt-labs/dbt-core#7905

## Checklist
- [x] Review the [Content style
guide](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/content-style-guide.md)
and [About
versioning](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/single-sourcing-content.md#adding-a-new-version)
so my content adheres to these guidelines.
- [ ] Add a checklist item for anything that needs to happen before this
PR is merged, such as "needs technical review" or "change base branch."
  • Loading branch information
mirnawong1 authored Oct 11, 2023
2 parents cf0a4e1 + 94fe6b6 commit 6edeee9
Showing 1 changed file with 8 additions and 0 deletions.
8 changes: 8 additions & 0 deletions website/docs/docs/collaborate/govern/project-dependencies.md
Original file line number Diff line number Diff line change
Expand Up @@ -100,3 +100,11 @@ There are a few cases where installing another internal project as a package can
- Coordinated changes — In development, if you wanted to test the effects of a change to a public model in an upstream project (`jaffle_finance.monthly_revenue`) on a downstream model (`jaffle_marketing.roi_by_channel`) _before_ introducing changes to a staging or production environment, you can install the `jaffle_finance` package as a package within `jaffle_marketing`. The installation can point to a specific git branch, however, if you find yourself frequently needing to perform end-to-end testing across both projects, we recommend you re-examine if this represents a stable interface boundary.

These are the exceptions, rather than the rule. Installing another team's project as a package adds complexity, latency, and risk of unnecessary costs. By defining clear interface boundaries across teams, by serving one team's public models as "APIs" to another, and by enabling practitioners to develop with a more narrowly-defined scope, we can enable more people to contribute, with more confidence, while requiring less context upfront.

## FAQs

<details>
<summary>Can I define private packages in the <code>dependencies.yml</code> file?</summary>

If you're using private packages with the [git token method](/docs/build/packages#git-token-method), you must define them in the `packages.yml` file instead of the `dependencies.yml` file. This is because conditional rendering (like Jinja-in-yaml) is not supported.
</details>

0 comments on commit 6edeee9

Please sign in to comment.