CLI: eco --ui {shell,lab,voila,desktop} -> subcommands eco {console,desktop,
webapp,jupyterlab}, console being the default (bare `eco` == `eco console`).
desktop's -s/--scope has no forced default any more: without it you get a
plain embedded Qt console with no Namespace launcher panel, instead of
silently defaulting to bernina. Both desktop and jupyterlab get a
--console/--no-console flag (console on by default). jupyterlab, when given
-s, now registers a real eco-<scope> Jupyter kernel (IPython profile startup
file + kernelspec, regenerated each launch) and makes it JupyterLab's
default kernel, then opens a real `jupyter console` on it in the launching
terminal -- so a fresh Console/Notebook opened from JupyterLab's own
launcher gets eco.<scope> preloaded too, not just one pre-built notebook.
Also added --set-rcfile [PATH] to persist the current invocation into an
.ecorc instead of launching.
Real bug found and fixed: Namespace.append_obj writes constructed/lazy
device objects onto sys.modules[root_module] (the scope module, e.g.
eco.bernina), not onto the Namespace instance itself -- the instance only
tracks name -> state bookkeeping (lazy_items/failed_items/initialized_items).
eco.widgets.desktop_app's launcher panel and console-namespace-population
both assumed `getattr(namespace, name)` worked, which silently raised
AttributeError for every single namespace entry -- opening or initializing
anything from the desktop launcher failed outright. Added
Namespace.resolve_item() as the canonical fix (the lazy-or-failed-or-
initialized dict chain reinitialize() itself already used internally) and
build_namespace_vars() (mirrors `from eco.<scope> import *` -- bare names
like mono/att, not just a `namespace` variable) for both the in-process and
subprocess console-kernel paths.
Also ported this same fix to eco.widgets.widget_tray (the ipywidgets
dashboard backing webapp/jupyterlab), replacing the old status_collection-
based member dropdown (initialized-only, no lazy/failed visibility) with a
NamespaceLauncherWidget matching desktop's launcher: browse every
registered name including lazy/failed ones, click to initialize+open.
New: a Required column/checkbox (Namespace.required_names()) in both
launchers -- desktop's Qt _NamespaceLauncher (QListWidget -> QTableWidget,
Name + Required columns) and the new ipywidgets NamespaceLauncherWidget.
Verified via eco-dev across all four subcommands against the real bernina
scope (shell/console, desktop with and without -s, webapp, jupyterlab
including the registered-kernel mechanism via a live jupyter_client
KernelManager), plus the full test suite (44/44 in test_desktop_app.py,
323/325 overall -- the 2 failures are pre-existing in
test_config_lazy_init.py, unrelated to any of this).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
eco shipped its own subpackage literally named eco/epics/, colliding with
the third-party `epics` (pyepics) package. Whenever eco's own package
directory landed on sys.path, `import epics.pv` resolved to eco's shadow
instead of pyepics. The previous commit patched one trigger (eco_cli.py's
shell UI), but --ui lab/voila hit the identical collision via a different
route: voila_app.ipynb lives inside eco/, and Jupyter/Voila kernels start
with the notebook's own directory as sys.path[0]. Confirmed via eco-dev:
both lab and voila's dashboard execution failed with the exact same
ModuleNotFoundError: No module named 'epics.pv'.
Renaming the subpackage (eco.epics -> eco.epics_utils, ~90 mechanical
import-line updates) removes the collision at the root, regardless of
trigger. Verified via eco-dev across all four --ui modes (shell, lab,
voila, desktop) with no more epics.pv errors anywhere.
Also reworked eco_cli.py's --help: shows [default] on -l/--lazy, adds a
full description of all four --ui front-ends including desktop, documents
.ecorc configuration, and adds --set-rcfile [PATH] to persist the current
invocation's scope/profile/lazy/ui into an .ecorc instead of launching.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
lemke_h
