fix(dlt): surface underlying error and hint when attaching to pipeline fails

[nkwork9999]

Description

Fixes #5660.

When sqlmesh init -t dlt --dlt-path <path> cannot attach to the pipeline, the underlying dlt error is swallowed and replaced with an uninformative Could not attach to pipeline <name> message.

The root cause of the confusion in #5660 is that --dlt-path must point to dlt's pipelines working directory (where pipeline state is stored, by default ~/.dlt/pipelines), not the directory containing the pipeline scripts — and both the help text and the swallowed error gave the user no way to discover that.

This PR:

• Surfaces the original dlt exception and the directory that was searched.
• Adds a hint to omit --dlt-path when a pipeline with the given name exists in the default pipelines working directory (the exact scenario in [bug] DLT Error: Could not attach to pipeline #5660).
• Clarifies the --dlt-path help text, docstring, and CLI docs.

Before:

Error: Could not attach to pipeline sushi

After:

Error: Could not attach to pipeline sushi.
Searched in: ./scripts
Pipeline with `pipeline_name=sushi` and `pipelines_dir=./scripts/sushi` could not be restored: No local pipeline state found in './scripts/sushi'.
...
Hint: A pipeline named 'sushi' exists in the default pipelines working directory '/Users/nk/.dlt/pipelines'. Note that --dlt-path must point to the directory where DLT stores pipeline working state (by default ~/.dlt/pipelines), not the directory containing your pipeline scripts. Try omitting --dlt-path.

Test Plan

• uv run --extra dev --extra web --extra slack --extra dlt --extra lsp make style
• uv run --extra dev --extra web --extra slack --extra dlt --extra lsp pytest tests/cli/test_cli.py -q (the one failure, test_plan_very_verbose, also fails on main in my environment and is unrelated)
• Extended the existing test_dlt_pipeline test to assert that the error reports the searched directory and the --dlt-path hint.

Checklist

• I have run make style and fixed any issues

[StuffbyYuki]

@nkwork9999 Thanks for this PR!

Some feedback:

docs/reference/cli.md has been updated but not the main dlt guide (docs/integrations/dlt.md), which still says things like:

"Specify the path to the pipelines directory"
--dlt-path <pipelines-directory>

Suggest aligning this doc with the new help text — e.g. "pipelines working directory" and clarifying it stores pipeline state, not scripts.

Another one is updating sqlmesh/magics.py help strings, --dlt-path help in magics.py (for both init and dlt_refresh IPython magics).

Let me know if I'm missing anything!

[nkwork9999]

Thanks for the reply and review! I updated docs/integrations/dlt.md to use "pipelines working directory" throughout and clarify that --dlt-path points to the directory where dlt stores pipeline state, not the directory containing pipeline scripts.

I also aligned the --dlt-path help strings in sqlmesh/magics.py for both the init and dlt_refresh IPython magics.

Verified with:

• uv run --extra dev --extra web --extra slack --extra dlt --extra lsp ruff check sqlmesh/magics.py
• uv run --extra dev --extra web --extra slack --extra dlt --extra lsp pytest tests/cli/test_cli.py::test_dlt_pipeline -q

Please check it!

[nkwork9999]

I also looked into the failing dbt-version CI jobs. The previous run was failing for both dbt 1.6 and 1.7 when importing Snowflake pulled in an incompatible pyOpenSSL/cryptography combination and raised AttributeError: module 'lib' has no attribute 'GEN_EMAIL'.

I added pyOpenSSL>=25.3.0 to the dbt 1.6 and 1.7 Makefile overrides so those matrix environments resolve a compatible OpenSSL wrapper.

Verified locally with:

• uv run pytest tests/dbt/test_config.py::test_snowflake_config tests/dbt/test_config.py::test_snowflake_config_private_key tests/dbt/test_config.py::test_snowflake_config_private_key_path tests/dbt/test_config.py::test_snowflake_config_oauth_access_token tests/dbt/test_config.py::test_api_class_loading --no-header -q
• a dbt 1.6 + pydantic 2 temp venv smoke check for the Snowflake config/API path

The latest GitHub Actions runs are currently showing action_required before jobs start, so they may need approval/re-run from a maintainer.

Please check it!

[StuffbyYuki]

@nkwork9999 oh thanks so much for looking into the dbt ci jobs error! I just ran the workflows

[StuffbyYuki]

@nkwork9999 Oh wait actually, somebody else merged a PR that had these fixes. Once rebase it should work just fine