Hello @Maxrb , I did some digging on my end and I have some suggestions and/or hints to help you further troubleshoot your issue.
What youโre running into lines up with a few runtime-specific behaviors that changed around Databricks Runtime 17.x, and together they explain why package discovery suddenly went quiet after the move to 17.2.
What likely changed
First, the current working directory on Databricks is the directory of the running notebook or script, not necessarily your repo root. If your packages live somewhere elseโsay at the repo root or under a src folderโthen pkgutil.walk_packages([os.getcwd()]) will simply never see them. Itโs scanning the wrong place.
Second, when youโre importing Python code from workspace files or Git folders that live outside the notebookโs directory, you need to be explicit about sys.path. The root of a Git folder is automatically added, but subdirectories are not. And if youโre working with workspace files, the path you append must include the /Workspace/โฆ prefix. If Python canโt see the directory, pkgutil wonโt either.
Finally, across the 17.x line there were changes to Python import hooks that tightened up how workspace paths are handled. A related issue showed up in 17.3 with wheel tasks, but even in 17.2 the behavior is more strict and predictable. Code that implicitly relied on os.getcwd() pointing at the repo root can now fail if the notebook lives in a subfolder.
Quick sanity checks
Before changing anything, itโs worth confirming what Python thinks is going on:
Print the working directory and its contents:
print(os.getcwd())
print(os.listdir(os.getcwd()))
This tells you immediately whether youโre scanning a directory that actually contains your packages.
Also double-check that your packages include an init.py. pkgutil.walk_packages only discovers classic packages; it wonโt enumerate PEP 420 namespace packages.
Recommended fixes
Which fix you choose really depends on where your code lives.
Option 1: Point pkgutil directly at your repo code (my preferred approach)
If your packages live under something like /Workspace/Repos///src, be explicit. Add that directory to sys.path and walk it directly:
import os
import sys
import pkgutil
repo_root = "/Workspace/Repos/<user>/<repo>"
src_dir = os.path.join(repo_root, "src") # or repo_root if you donโt use src/
if src_dir not in sys.path:
sys.path.append(src_dir)
packages = list(pkgutil.walk_packages([src_dir]))
print(packages)
This removes all ambiguity about what youโre scanning and what Python can import.
Option 2: Let sys.path do the work
If your notebook lives at the Git folder root (not nested), that root is already on sys.path. In that case you can just let pkgutil walk everything Python already knows about:
import pkgutil
packages = list(pkgutil.walk_packages())
print(packages)
This only works if your layout is clean and flat, but when it applies, itโs the simplest solution.
Option 3: Compute the repo root from the notebook location
If your notebook is nested a few levels down, compute the repo root relative to the working directory and add it:
import os
import sys
import pkgutil
cwd = os.getcwd()
repo_root = os.path.dirname(os.path.dirname(cwd)) # adjust depth as needed
if repo_root not in sys.path:
sys.path.append(repo_root)
packages = list(pkgutil.walk_packages([repo_root]))
print(packages)
Why os.getcwd() started betraying you
In 17.x, Databricks is much more consistent about setting CWD to the notebookโs directory. If your code used to run from a location that happened to be the repo rootโand now runs from a subfolderโthen walk_packages([os.getcwd()]) will return nothing because itโs doing exactly what you asked: scanning the wrong directory.
That behavior lines up with the documented CWD semantics and the newer guidance around workspace files and Git folders. Nothing is โbrokenโ so much as more strictly defined.
Hope these tips get you over the finish line.
Cheers, Lou.
