orange3 - Moses Yebei

The Problem

Orange3 solves a specific problem: making data mining and visualization accessible to users without programming skills. It provides a visual workflow-based interface where users connect widgets (data loading, preprocessing, modeling, visualization) to explore data interactively. The target audience is analysts and domain experts who need to inspect data and build models without writing code.

What This Does

Orange3 is a Python desktop application built on PyQt. The core data structures live in Orange/data/ (table.py, variable.py, domain.py), handling tabular data with discrete and continuous variables. Machine learning algorithms are in Orange/classification/, Orange/regression/, and Orange/clustering/, with a common Learner/Model abstraction in Orange/base.py. The visual canvas interface is in Orange/canvas/, and widgets—the individual visual components—are in Orange/widgets/.

The project also includes benchmark/ for performance testing, doc/ with extensive reStructuredText documentation, and i18n/ for translations.

How It Is Wired

Execution starts at Orange/canvas/__main__.py, specifically the run function at line 88. This reaches 54 functions and makes outbound network calls via send_statistics (using requests.post). The main function at line 463 orchestrates application startup, reaching 19 functions. The application touches the filesystem through open_compressed (gzip file access) and _rm_tree (directory removal for settings cleanup).

The most critical module is Orange/data/__init__.py with 418 modules depending on it—a change there ripples across the entire codebase. The Domain class is called from 149 places and Table from 147, making them the highest-risk change points. The call graph shows test code dominates: setUpClass -> Table appears 120 times, and setUp -> create_widget 91 times.

The import graph shows 88 modules in circular dependencies, including Orange/data/__init__.py and Orange/classification/__init__.py. This makes incremental imports fragile and complicates refactoring.

How To Use It

Setup (from README):

conda config --add channels conda-forge
conda config --set channel_priority strict
conda create python=3.12 --yes --name orange3
conda activate orange3
conda install orange3

Running:

orange-canvas
# or
python3 -m Orange.canvas

For development, clone with submodules (.gitmodules is present) and install with pip install -e . after satisfying PyQt and C/C++ compiler requirements.

Real-World Use

A typical workflow: load a CSV with the File widget, connect it to Data Table (inspect rows), Scatter Plot (visualize), and Train Models (e.g., Random Forest). The workflow file format is .ows—examples are in Orange/canvas/workflows/. The user connects widgets visually, no code required.

Code Health & Issues

Static analysis found 694 issues (432 high, 254 medium, 8 low) across 5 categories:

High - Import cycle members (x14): Orange/data/__init__.py, Orange/classification/__init__.py participate in circular imports. Fix: extract shared types or defer imports.
High - Deep nesting (x20): Orange/widgets/tests/base.py has indentation depth 10. Fix: early returns and guard clauses.
High - Hub modules (x16): Orange/data/__init__.py has 418 dependents; churn here is high-blast-radius.
High - Oversized files (x5): Orange/widgets/tests/base.py is 923 lines.
Medium - Broad exception handling (x5): Orange/classification/__init__.py catches Exception indiscriminately.

SDLC observations:

High - Unpinned GitHub Actions: workflows use @v4 and @v3 tags, which can be moved. Pin to commit SHAs.
High - No lockfile: pyproject.toml exists but no lockfile, so builds are non-reproducible.
Medium - No Dependabot/Renovate: 9 manifests, no automated dependency updates.
Medium - No dependency vulnerability scan in CI.

Tests exist (397 files), CI runs GitHub Actions, and a license is present. No committed secrets found.

The Bottom Line

Orange3 is a mature, feature-rich data mining tool with strong documentation and testing. The circular imports and hub modules make core changes risky, and the lack of a lockfile is a supply-chain concern. It's a solid choice for non-programmers needing interactive data analysis, but developers should approach Orange/data/ with caution.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

1,141 files

Python748
reStructuredText38
YAML13
Markdown13
Shell5
C1

DjangoOpenCVpandas

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["Orange<br/>688 modules"] g1["doc<br/>47 modules"] g2["benchmark<br/>10 modules"] g3["(root)<br/>2 modules"] g1 -->|73| g0 g2 -->|21| g0

Module dependencies

The 10 most depended-upon modules of 748, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_Orange_data___init__["__init__"] n1_Orange_widgets___init__["__init__"] n2_Orange_widgets_tests_base["base"] n3_Orange_widgets_widget["widget"] n4__widgets_utils_widgetpreview["widgetpreview"] n5_ange_classification___init__["__init__"] n6_Orange_widgets_settings["settings"] n7_Orange___init__["__init__"] n8_Orange_preprocess___init__["__init__"] n9_Orange_regression___init__["__init__"] n6_Orange_widgets_settings --> n0_Orange_data___init__ n2_Orange_widgets_tests_base --> n0_Orange_data___init__ n2_Orange_widgets_tests_base --> n8_Orange_preprocess___init__ n2_Orange_widgets_tests_base --> n3_Orange_widgets_widget classDef cyc stroke:#ef4444,stroke-width:2px; class n0_Orange_data___init__,n5_ange_classification___init__,n7_Orange___init__,n8_Orange_preprocess___init__,n9_Orange_regression___init__ cyc;

Findings

LowDependencies declared without a lockfile - non-reproducible builds pyproject.toml

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high2

medium4

low1

Pin third-party GitHub Actions to a commit SHAhigh6 occurrences

.github/workflows

docker/setup-qemu-action@v4, pypa/cibuildwheel@v3.3.0, shogo82148/actions-upload-release-asset@v1.2.3, pypa/gh-action-pypi-publish@release/v1

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Commit a lockfile beside the manifesthigh

pyproject.toml

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Declare least-privilege permissions for GITHUB_TOKENmedium3 occurrences

.github/workflows/cancel.yml

3 workflow(s) declare no permissions, 1 of them reference secrets

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

9 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/build-wheels.yaml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow3 occurrences

.github/workflows/build-wheels.yaml

3 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.