added support to enable/disable packages

[sriramr98]

Resolves #7434

Problem

There is currently no way to conditionally enable or disable packages in packages.yml. Dev-only packages like codegen and audit_helper are always resolved and installed, even in production environments where they add unnecessary bloat and resolution time.

Solution

Adds an enabled field to all package types in packages.yml. The field supports static booleans and Jinja expressions with access to target, var() and env_var().

  packages:
    - package: dbt-labs/codegen
      version: 0.12.1
      enabled: "{{ target.name != 'prod' }}"

Behavior:

• enabled defaults to None (treated as enabled) — fully backward compatible
• Disabled packages are excluded from resolution, lock file, and installation
• Transitive dependencies with enabled: false (or Jinja-rendered false) are also skipped
• Skipped packages emit a log message for visibility

Jinja context available in enabled:

1. target
2. var()
3. env_var()

Checklist

• I have read the contributing guide and understand what's expected of me.
• I have run this code in development, and it appears to resolve the stated issue.
• This PR includes tests, or tests are not required or relevant for this PR.
• This PR has no interface changes (e.g., macros, CLI, logs, JSON artifacts, config files, adapter interface, etc.) or this PR has already received feedback and approval from Product or DX.
• This PR includes type annotations for new and modified functions.

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[codecov]

Codecov Report

❌ Patch coverage is 97.41935% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.96%. Comparing base (d8e45cf) to head (8e47634).
⚠️ Report is 17 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12567      +/-   ##
==========================================
- Coverage   91.42%   90.96%   -0.46%     
==========================================
  Files         203      203              
  Lines       25574    25725     +151     
==========================================
+ Hits        23380    23400      +20     
- Misses       2194     2325     +131     

Flag	Coverage Δ
integration	87.17% <92.90%> (-1.13%)	⬇️
unit	65.39% <68.38%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
Unit Tests	65.39% <68.38%> (+0.02%)	⬆️
Integration Tests	87.17% <92.90%> (-1.13%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[akbog]

Hey folks! Just want to flag a few things here that are potential 🚩/ that I think should be addressed before proceeding:

1. Do we fully understand how this feature can be used within contexts like cross-project mesh, deferral etc.?

My concern is that large projects are often the ones that benefit from conditional filtering of deps etc. if that becomes environment (or really to any generic condition) it can blow up the potentially complexity of managing projects (because manifest production / upstream dependencies are conditional). Usually frameworks have a way of specifying "dev" dependencies which are fully detached from being production build dependencies (see dev dependencies in rust).

2. Lock Files

Disabled packages are excluded from the lock file. This means the lock file becomes environment-specific, defeating its purpose (reproducible builds). Running dbt deps in dev vs prod produces different lock files. You can't commit a single lock file to your github repo for example.

3. No Compile-Time Safety

There's no validation that models in the project don't reference macros/models from a disabled package. If a model uses {{ codegen.generate_model_yaml(...) }} and codegen is disabled in prod, you get a runtime Jinja error, not a helpful compile-time error. This is a really popular foot gun I'd expect users to experience.

4. Profile Dependency for dbt deps

The PR (I believe) makes dbt deps profile-aware (via optional_profile()) - unless that is already the case. This is an important detail for CI/Docker environments where you install deps before configuring profiles. Subtle but potentially breaking change due to added dependency.

@sriramr98 - I'm in-person as you know and can chat re: the implementation details