Drop gitpython as a required dependency from dagster-dbt

[joshuataylor]

What's the use case?

Today:

And see https://github.com/gitpython-developers/GitPython/security

Can we please make this an optional dependency.

Ideas of implementation

gitpython is currently a hard, unpinned runtime dependency of dagster-dbt:

In python_modules/libraries/dagster-dbt/pyproject.toml

dependencies = [
    "dagster==1!0+dev",
    "dbt-core>=1.7,<1.12",
    "gitpython",   # <- always installed
    ...
]

But it's used in exactly one place, and it's already lazily imported so it has no import-time side effects:

In python_modules/libraries/dagster-dbt/dagster_dbt/dbt_project_manager.py

class RemoteGitDbtProjectManager(DbtProjectManager, Resolvable):
    def sync(self, state_path: Path) -> None:
        # defer git import to avoid side-effects on import
        from git import Repo

        Repo.clone_from(self._get_clone_url(), self._local_project_dir(state_path), depth=1)
        ...

That's it. Yes, it's bugged me for ages, and yes that's it. Just to do a a single shallow clone_from(..., depth=1).

No refs, fetch, pull, commits -- just a clone.

It's only used when someone configures a DbtProjectComponent with a RemoteGitDbtProjectManager (i.e. a remote repo_url).

The other managers (NoopDbtProjectManager, DbtProjectArgsManager, for local project dirs) never touch git.

So every dagster-dbt user pays for gitpython (and inherits its CVE surface -- https://github.com/gitpython-developers/GitPython/security) even though the vast majority never use the remote-git feature.

Proposed implementation (opt-in extra)

1. Move gitpython out of the core dependencies array and into an optional extra:

[project.optional-dependencies]
git = ["gitpython"]

1. Installed on demand via pip install dagster-dbt[git] / uv add "dagster-dbt[git]".
2. Turn the lazy import in sync() into a guarded one that raises an actionable error when the extra isn't installed (matching the existing "X is not installed" pattern already used elsewhere in dagster-dbt, e.g. utils.py, scaffolder.py):

try:
    from git import Repo
except ImportError:
    raise DagsterImportError(
        "Using `RemoteGitDbtProjectManager` requires the `git` extra. "
        "Install it with `pip install dagster-dbt[git]`."
    )

3. Keep the existing tests green -- they patch git.Repo.clone_from (test_dbt_project_component_remote.py), so the test env just needs gitpython available (add it to the test dependency group).

Net effect: no behaviour change for anyone using local dbt projects, gitpython disappears from the default install, and remote-git users get a clear one-line instruction to enable it.

Related issue: #34091

Alternative considered:

1. Dropping gitpython entirely and shelling out to git clone --depth 1 via subprocess.

   GitPython only wraps the git CLI for clone_from anyway, and the git binary is a prerequisite either way.

This removes the dependency completely rather than making it optional, at the cost of rewriting the tests that patch git.Repo.clone_from. Happy to go this route instead if maintainers prefer zero dependency over an opt-in extra.

Additional information

I'm tired, boss.

Message from the maintainers

Impacted by this issue? Give it a 👍! We factor engagement into prioritization.

[varunbiluri]

I reviewed the current dagster-dbt packaging path and the two approaches described here appear to have materially different compatibility implications:

1. Move GitPython behind a git extra and raise a targeted runtime error only when prepare-and-package is used without it.
2. Remove GitPython and invoke the system git executable for the shallow clone.

The first preserves the existing implementation but changes installation guidance and runtime dependency behavior. The second removes the Python dependency entirely but introduces a system-executable requirement and subprocess/error-handling surface.

I have not started an implementation because choosing between these is a maintainer-level dependency/API decision. Which direction would you prefer for an external contribution? Once confirmed, I can keep the patch focused and add coverage for both the successful clone path and the missing dependency/executable error path.

[joshuataylor]

As mentioned, gitpython is used in exactly one spot: the shallow clone in RemoteGitDbtProjectManager.sync.

BTW, GitPython's Repo.clone_from does not actually implement git itself -- it shells out to the git CLI anyway...

So we can replace it with what gitpython does under the hood, and remove the dependency entirely.