emzed.spyder

emzed.spyder is a customized distribution of the Spyder IDE for the emzed mass spectrometry platform (ETH Zurich, Scientific IT Services).

emzed Related Functions in the Spyder Terminal

remote_interpreter_startup.py is injected as the IPython kernel startup file. Because it runs as a startup script, everything defined at its top level lands directly in the user namespace — including emzed itself (preloaded) and all emzed_* helper functions listed below:

To separate projects with separated virtual environments or to create emzed extensions:

Run emzed_help() in the console for a full listing.

Project locations on disk

Projects are stored in a platform-specific folder:

• macOS/Linux: ~/.emzed3_projects/<project_name>/
• Windows: %APPDATA%\emzed3_projects\<project_name>\

Each project folder contains a .venv/ subdirectory with the project's own Python environment.

Project workflow

emzed_project_new(name) scaffolds a new project using a cookiecutter template. It:

1. Creates the project folder under the projects directory above.
2. Generates a setup.py, requirements_dev.txt, LICENSE.txt, and a src/emzed_ext_<name>/ package skeleton.
3. Creates a .venv/ that inherits emzed and its dependencies from the shared remote venv (via a .pth file), so only project-specific packages need to be installed on top.
4. Activates the new project and opens setup.py in the editor.

After editing setup.py and requirements_dev.txt, run emzed_project_update() to install the project and its dependencies into the project venv.

emzed_project_activate(name) switches the active project — the next IPython console that opens will use that project's .venv as its Python interpreter and start in the project folder. Only one project can be active at a time; emzed_project_deactivate() returns to the default remote venv.

Variable Explorer Integration

emzed_spyder_kernels.py runs inside the remote kernel and patches spyder_kernels.utils.nsview so that emzed-specific types display correctly in Spyder's variable explorer:

These patches must live in the kernel process (not Spyder's process) because the variable explorer inspects live objects — but isinstance checks cannot be used from the Spyder side, since emzed is only installed in the remote venv. Instead, patch_gui.py detects Table/PeakMap by the type name string returned from the kernel when a double-click occurs, then calls _inspect() directly in the remote shell to open the viewer without copying data across the process boundary.

Architecture

The project is a thin wrapper around Spyder that patches it at startup time. It does not fork Spyder — it installs alongside it and monkey-patches live classes before Spyder finishes booting.

Entry point: emzed_spyder.start:main imports patch_all, then delegates to spyder.app.start.main.

Patch modules (applied in strict order)

The ordering is critical: set_remote_python_interpreter must run after all config patches because Spyder caches some config at import time.

Two-Venv Model

emzed.spyder uses two separate Python environments:

• Spyder venv — runs the IDE itself (PyQt5, Spyder, emzed_spyder)
• Remote venv (~/.emzed3/remote_venv/) — runs user code; contains emzed, emzed_gui, emzed_spyder_kernels

At startup, the remote venv is validated (required packages are imported to confirm they work) and recreated from scratch if invalid, downloading setup files from GitLab.

User projects each get their own .venv that inherits from the remote venv via a .pth file, avoiding re-installation of the heavy emzed stack.

CI/CD and Tooling

• CI: GitLab CI (.gitlab-ci.yml)
• Linting: ruff, black, flake8 via pre-commit hooks
• Dependency management: uv
• Platform notes: PyQt5 is pinned on Windows; uv environments are scoped to Linux and Windows (macOS uses system Qt)