Hmmm, I have not personally experienced this. I dug a little deeper in our internal docs and and leveraged some internal tools to put togehter another approach for you.  Please give this a try and let me know.

You’re running into a subtle but very real behavior change in Databricks Runtime 17.2, and it shows up most clearly when using pkgutil.walk_packages() with the current working directory.

This isn’t your code suddenly “breaking.” It’s the interaction between Python’s import system and how DBR 17.2 (now on Python 3.12) treats discovery paths.

Let’s walk through it.

The root cause

pkgutil.walk_packages() doesn’t just crawl a filesystem path. It expects that path to behave like a real Python import location:

• The directory must contain proper packages (__init__.py)

• And just as importantly, the directory must be reachable through Python’s import machinery

In DBR 17.2, relying on os.getcwd() alone is no longer sufficient. Even if the files are there, Python won’t reliably discover them unless that directory is also present on sys.path. Earlier runtimes were more forgiving; Python 3.12 is not.

That’s why walk_packages() suddenly appears to return nothing.

The most reliable fix

Option 1: Explicitly add the directory to

sys.path

This aligns your filesystem view with Python’s import system and works consistently:

import pkgutil
import os
import sys

cwd = os.getcwd()
if cwd not in sys.path:
    sys.path.insert(0, cwd)

packages = pkgutil.walk_packages([cwd])
print(list(packages))

This is the safest pattern and the one I recommend in most Databricks notebooks.

A cleaner alternative for repos

Option 2: Use an absolute workspace path

If your code lives in a repo or workspace folder, be explicit about where packages live instead of relying on the notebook’s working directory:

import pkgutil
import os

repo_path = os.path.abspath("/Workspace/path/to/your/repo")
packages = pkgutil.walk_packages([repo_path])
print(list(packages))

This avoids ambiguity entirely and plays nicely with Git folders and workspace imports.

One more thing to double-check

Make sure your package structure is real Python, not just folders that “look” like packages.

Every directory you expect to be discovered must include an __init__.py. Python 3.12 is noticeably stricter here, and DBR 17.2 surfaces that reality.

Why this showed up in 17.2

DBR 17.2 includes a Python upgrade to 3.12.x, along with internal changes to import handling. pkgutil.walk_packages() has always required paths to be importable—but earlier runtimes were more lenient when the current working directory happened to work by accident.

In short:

What used to work implicitly now needs to be explicit.

That’s not a regression—it’s Python behaving the way it always documented itself.

Regards, Louis.