[BUG] FiftyOne crashes on startup when installed under non-standard filesystem roots (e.g. /sc/...)

[philippkolbe]

When running FiftyOne on machines where Python or the FiftyOne plugins directory resides under a non-standard filesystem root (e.g. /sc/...), the FiftyOne App crashes immediately when loading a dataset.

The backend fails during plugin registration with:

Error: Operator "@voxel51/operators/list_workspaces" not found
    at getLocalOrRemoteOperator (http://localhost:5151/datasets/assets/index-CaQ_cEQV.js:5137:11871)
    at useOperatorExecutor (http://localhost:5151/datasets/assets/index-CaQ_cEQV.js:5137:38330)
    at useInvocationRequestExecutor (http://localhost:5151/datasets/assets/index-CaQ_cEQV.js:5137:40626)
    at RequestExecutor (http://localhost:5151/datasets/assets/index-CaQ_cEQV.js:9179:2129)
    at Xh (http://localhost:5151/datasets/assets/index-CaQ_cEQV.js:31:21729)
    at Wk (http://localhost:5151/datasets/assets/index-CaQ_cEQV.js:33:48569)
    at Vk (http://localhost:5151/datasets/assets/index-CaQ_cEQV.js:33:43841)
    at Uk (http://localhost:5151/datasets/assets/index-CaQ_cEQV.js:33:43762)
    at Jk (http://localhost:5151/datasets/assets/index-CaQ_cEQV.js:33:43602)
    at Ok (http://localhost:5151/datasets/assets/index-CaQ_cEQV.js:33:39578)

This appears to be caused by dynamic plugin imports deriving Python module names from absolute filesystem paths. In the console we can see the deeper cause:

Traceback (most recent call last):
  File "/sc/home/philipp.kolbe/conda3/envs/jid/lib/python3.14/site-packages/fiftyone/plugins/context.py", line 162, in register_all
    spec.loader.exec_module(module)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^
  File "<frozen importlib._bootstrap_external>", line 759, in exec_module
  File "<frozen importlib._bootstrap>", line 491, in _call_with_frames_removed
  File "/sc/home/philipp.kolbe/conda3/envs/jid/lib/python3.14/site-packages/plugins/operators/__init__.py", line 25, in <module>
    from .model_evaluation import ConfigureScenario, ConfigureScenarioPlotResolver
  File "/sc/home/philipp.kolbe/conda3/envs/jid/lib/python3.14/site-packages/plugins/operators/model_evaluation/__init__.py", line 16, in <module>
    from .utils import (
    ...<9 lines>...
    )
ModuleNotFoundError: No module named 'sc'

The frontend crashes immediately after dataset load.

Code to reproduce issue

This can be reproduced on any Linux system by:

1. Installing Python / FiftyOne under a non-standard root, e.g. /sc/home/...
2. Launching the FiftyOne app
3. Selecting a dataset

import fiftyone as fo
import fiftyone.zoo as foz

# Load a built-in sample dataset (no local data required)
dataset = foz.load_zoo_dataset("quickstart", max_samples=5)

# Launch the FiftyOne App
session = fo.launch_app(dataset)

# Keep the process alive
session.wait()

System information

• OS Platform and Distribution: Linux 6.8.0-88-generic x86_64 GNU/Linux
• Python version: 3.14.2
• FiftyOne version: FiftyOne v1.11.0, Voxel51, Inc.
• FiftyOne installed from: pip (via uv in conda environment)

Other info/logs

In context.py during plugin registration, FiftyOne dynamically imports plugin modules via:

spec = importlib.util.spec_from_file_location(module_name, module_path)
spec.loader.exec_module(module)

The module_name is derived from filesystem paths using:

module_name = fou.get_module_name(module_dir, fo.config.plugins_dir)

When FiftyOne (or its plugins) are installed under a filesystem path such as /sc/home/... the computed module_name can unintentionally start with sc, causing Python to interpret it as a top-level package sc.home.philipp.kolbe....

This leads to:

ModuleNotFoundError: No module named 'sc'

This is similar in nature to known issues on Windows where dynamic imports incorrectly interpret drive letters (C:) as module names.

Instead of deriving module names from filesystem paths, dynamically loaded plugins should use:

• synthetic module names, or
• a fixed namespace such as fiftyone.plugins.<plugin_name>
  This would avoid filesystem-dependent import behavior.

Willingness to contribute

The FiftyOne Community encourages bug fix contributions. Would you or another
member of your organization be willing to contribute a fix for this bug to the
FiftyOne codebase?

• Yes. I can contribute a fix for this bug independently
• Yes. I would be willing to contribute a fix for this bug with guidance
  from the FiftyOne community
• No. I cannot contribute a bug fix at this time

[ritch]

@philippkolbe are you able to try out this branch? #6749

I am not able to reproduce the issue outside pytest.

[AdonaiVera]

Hi @philippkolbe, thanks for reporting this!

I was able to reproduce the issue with the following steps:

1. Create a fresh virtualenv and install FiftyOne:

   pip install fiftyone
   

2. Rename or move the builtin plugins directory:

   site-packages/plugins/
   

3. Run the app → the UI shows "Operator not found"

The root cause is that site-packages/plugins/ contains the builtin plugins, including @voxel51/operators, where list_workspaces is defined.

If this directory is missing or unreachable, builtin operators fail to register silently, which leads to the error you're seeing in the App.

The issue comes from how the path is resolved in the code (via relative path traversal), which can break depending on how and where FiftyOne is installed.

Workaround:

pip uninstall fiftyone
pip install fiftyone

A full uninstall + reinstall (not --force-reinstall) restores the directory correctly.

We’re looking into making builtin plugin discovery more robust so this doesn’t fail silently. Let me know if you’re seeing anything different in your environment.