Fix python interpreter issue#24
Draft
CopyDemon wants to merge 34 commits into
Draft
Conversation
Use the VS Code Python extension's active interpreter to run fi-steps directly (no shell, no conda activate), fixing Windows conda/PATH pain and supporting any env manager (conda/venv/pyenv). Re-run steps and clear stale warnings when the user switches interpreter. Declare ms-python.python as an extension dependency. Also rename the IDAES-branded view ids/titles to fi / Flowsheet Inspector and ignore the bundled webview assets in eslint.
Contributor
|
I think the gist of this solution is correct, but I don't see |
List every interpreter the Python extension has discovered and broadcast it (with the active one) as python_env_update on webview ready, on interpreter change, and as async discovery progresses (debounced). Force a refreshEnvironments() pass when the list is empty so the first render isn't blank. Handle a change_python_env instruction that switches the active interpreter via the Python extension API, keeping the status bar and our UI in sync.
Store the python_env_update payload (active interpreter + discovered envs) in app context and render a labeled dropdown above the step list. Picking an env sends change_python_env to the extension host, which switches the interpreter and re-runs fi-steps. Move the new block's styles into tree_app.module.css and reuse the shared dropdown class for the flowsheet selector.
Document checkActivePythonEnv and runFiSteps in detail: what each does, why it sits where it does in the flow, parameters, return shapes, and failure modes.
Previously the extension shelled out to the sqlite3 CLI binary for all database reads (history polling, post-run report fetch, historical run load). This required sqlite3 to be installed on the user's machine and was fragile on systems where it was absent. Switch to node-sqlite3-wasm (pure WebAssembly, no native addon) so the user never needs sqlite3 installed. Centralise all DB access in the new sqlite_reader.ts module which also handles: - Modern vs legacy schema detection via PRAGMA table_info - Python json.dumps Infinity/NaN sanitisation before JSON.parse - Uint8Array → string coercion for TEXT columns that node-sqlite3-wasm returns as bytes Remove buildSqliteCommand, buildSqliteFallbackCommand, and getStderrRedirect from platform_config.ts as they are no longer needed.
… required packages installed or not
… is undefined, it going to check visiable file to make sure it can read a file.
Replace the shell-based runner (source ~/.zshrc && conda activate && fi-run) with direct subprocess spawning via the interpreter resolved from the VS Code Python extension API — matching how fi-steps already works. - run_terminal_command: new signature (executable, args, childEnv); spawns the process directly instead of wrapping in a shell - run_flowsheet: drop extensionConfig/shell/conda dependency; resolve env via getActivePythonEnv, locate fi-run with pythonToolPath, inject PATH via activatedProcessEnv — works on Windows without any extra user config - extension_initial_check: remove dead checkExtensionConfigEnv, shellExists, and execPromise (old shell-based env check, no longer called anywhere)
Replace pythonToolPath console-script spawning with direct interpreter + -m: fi-steps: python -m idaes_fi.structfs.common --fs <file> -t json fi-run: python -m idaes_fi.structfs.fsrunner <file> [--last <step>] This is simpler and more robust — no reliance on console scripts being present in bin/Scripts, works correctly with any environment manager.
…eview can't load python interpretor
Unconditionally calling refreshEnvironments() on every sidebar open caused a slow full environment scan on machines with many Python environments, blocking the UI until discovery completed. Now only trigger the refresh when the initial broadcast returns an empty env list — the common case where envs are already known skips the scan entirely. New environments installed during the session are still picked up via the onDidChangeKnownPythonEnvs debounced listener.
Shell path, source command, and conda activate config are dead code after migrating fi-steps and fi-run to direct interpreter spawning via `python -m`. Deletes extensionHandler, setDefaultExtensionConfig, configView, config.module.css and removes all related state, message handlers, and UI from the sidebar component tree.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On Windows, the extension has a conda / PowerShell conflict. When conda is installed on Windows, it doesn't add itself to PATH, so PowerShell reports conda is not recognized as a command. To work around this, users currently have to run conda init powershell manually and add extra flags (e.g. changing the execution policy), which is a poor experience.
Solution
Instead of activating conda / miniforge / venv inside a shell, we use the VS Code Python extension to run the user's currently selected interpreter directly as the execution environment. This avoids any shell-based activation and works with any environment manager.