This pattern - one package sits at "resolving" for 30+ minutes while everything else installs fine - is almost always pip's backtracking resolver rather than a PyPI outage. databricks-langchain pulls a deep tree (langchain-core, langgraph, mlflow, pydantic, tenacity, ...) and several of those have constraints that clash with what DBR 16.4 / 17.3 already ship, so pip walks backwards through old releases trying to find a consistent set, downloading each one.
What has worked for us:
1. Run it notebook-scoped with -v so you can actually see it: %pip install -v databricks-langchain. If you see "This is taking longer than usual... backtracking", that confirms it is dependency resolution.
2. Constrain the tree so pip does not backtrack. Pin the package plus its heavy deps to versions compatible with the runtime, e.g. %pip install "databricks-langchain==<latest on PyPI>" "mlflow==<the version already on the runtime>" "langchain-core>=0.3,<0.4". The upper bounds matter more than the exact pins.
3. Add --only-binary=:all: to rule out a source build. If a transitive dep has no wheel for the runtime's Python (3.12 on both 16.4 and 17.3), pip tries to compile it, which looks like a hang. --only-binary=:all: fails fast and names the offender.
4. Cluster-UI library installs retry silently and are hard to watch - use %pip while iterating, then move the working pin set to the cluster library list or an init script once it resolves.
5. Longer term, do not resolve this on every cluster start. Bake the pinned set into an init script, a serverless environment spec, or a custom container, and/or point pip at an Azure Artifacts PyPI cache so you are not re-hitting pypi.org each time.
If it still hangs with a fully pinned --only-binary command, grab the -v log - the last few lines before it stalls will name the package it cannot satisfy.
