Skip to content

Add updated Colab notebook (Python 3.12, PyTorch 2.11+, MMCV 2.2+ compatibility) - #325

Open
shawnsony07 wants to merge 1 commit into
Seeed-Studio:mainfrom
shawnsony07:fix-python312-colab-compatibility
Open

Add updated Colab notebook (Python 3.12, PyTorch 2.11+, MMCV 2.2+ compatibility)#325
shawnsony07 wants to merge 1 commit into
Seeed-Studio:mainfrom
shawnsony07:fix-python312-colab-compatibility

Conversation

@shawnsony07

Copy link
Copy Markdown

Overview

This PR adds an updated, generic Colab Notebook template (SSCMA_Swift_YOLO_Colab_Template.ipynb) to resolve critical dependency conflicts and compilation errors when running the training and export pipeline in modern Google Colab environments.

Key Fixes Included in the Notebook:

  1. MMCV Version Limits (mmdet & mmcls): Dynamically patches __init__.py in both libraries at runtime to bypass the hardcoded 2.2.0 upper limit, preventing AssertionError crashes on import.
  2. PyTorch 2.6+ torch.load Security Check: Adds a lightweight wrapper to bypass the new weights_only=True default during training and export.
  3. Export Dependencies: Explicitly installs the complete ONNX stack and missing mmcls requirements in the setup cell.

Copilot AI lite review requested due to automatic review settings August 27, 2026 09:50

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@iChizer0

Copy link
Copy Markdown
Contributor

Hi @shawnsony07, thank you so much for digging into this, and for a genuinely thoughtful write-up. Your diagnosis was spot-on and saved us real time.

We ended up addressing these at the repo level rather than merging the notebook, for a few reasons:

  • The root causes lived in our requirements/scripts (e.g. torch<=2.0.1 pins with no Python 3.12 wheels, and openmim's transitive openxlab dep pinning setuptools~=60.2.0, your instinct was exactly right). Fixing them there helps every user, not just notebook users.
  • Runtime-patching installed packages and rewriting tools/*.py is fragile, we replaced it with a maintained scripts/patch_mmlab_versions.py (which fails loudly if versions drift) and PyTorch's official TORCH_FORCE_NO_WEIGHTS_ONLY_LOAD=1 escape hatch.
  • One extra landmine surfaced during testing: pip silently replaces the preinstalled torch when later installs depend on it (e.g. via pnnx), which breaks a pre-compiled mmcv, so setup ordering and a constraints file matter a lot.

The result is on branch fix/colab-py312: a rebuilt scripts/setup_colab.sh plus updated requirements, and the existing Colab notebook now just calls that script. We verified the full flow end-to-end on Python 3.12.

We'd love it if you could give the new branch a spin in Colab and tell us whether it works for your Grove Vision AI V2 use case, thanks again for pushing this forward.

@shawnsony07

Copy link
Copy Markdown
Author

Hi @iChizer0 ,

Thank you so much for taking the time to look into this and for working on a repo-level solution! My main motivation behind opening the PR was to make sure developers training custom models for the Grove Vision AI V2 could run through the Colab notebooks smoothly without hitting frustrating dependency roadblocks.

I gave the fix/colab-py312 branch a test on a clean Google Colab instance and ran into a small issue during scripts/setup_colab.sh.

When pip attempts to install ethos-u-vela-3.7.0.tar.gz (building from source on Python 3.12), building the wheel fails during subprocess requirement gathering:

Downloading ethos-u-vela-3.7.0.tar.gz
error: subprocess-exited-with-error
× Getting requirements to build wheel did not run successfully.

Because setup_colab.sh exits on this error, downstream packages (mmdet, mmcv, etc.) are never installed, causing ModuleNotFoundError: No module named 'mmdet' when running tools/train.py.

Pre-installing setuptools, wheel, and flatbuffers prior to ethos-u-vela resolved the build failure on my end.

Thanks again for taking this up and driving the architectural refactor forward.

@iChizer0

iChizer0 commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Hi @shawnsony07, thanks again for this PR and for your patience. Your report pushed us into a full review of the Colab toolchain; here's where things stand.

We found Google silently upgraded Colab from Python 3.12 to 3.13 - their runtime FAQ hasn't been updated yet. That's very likely why earlier fixes stopped working: 3.13 changed exec()/locals() semantics (PEP 667, which breaks the mmcv build), numpy 1.x has no cp313 wheels, and most of the preinstalled stack now requires numpy >= 2.
20260828-063340

And we've fully adapted the project to Python 3.13 on two fix branches:

  • fix/colab-py312-main (recommended): Swift-YOLO re-implemented on our own vendored stack - no MMCV/MMDet at all, plain pip install setup, and the exported INT8 model compiles to 100% NPU operators on Ethos-U55.
  • fix/colab-py312: keeps the 2.0.0 MMDet pipeline. MMDet needs MMCV, which pypi is unmaintained (~2 years) and has no wheels for modern Python/PyTorch - it builds from source, taking ~30 min on Colab and sometimes stalling the instance. Works, but not a great experience.

(Branch names are historical - created when Colab was still on 3.12.)

We'd like to hold this PR open for now: main and 2.0.0 have diverging commit histories that we need time to reconcile, and we'd rather land one coherent fix than a moving notebook patch.

Meanwhile, could you try the fix branch and tell us if it resolves your issue?

!git clone -b fix/colab-py312-main https://github.com/Seeed-Studio/ModelAssistant.git

Let's get your problem solved first, we'll follow up here once the branches are settled.

@mjq2020

mjq2020 commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

Thanks for the contribution. Please recreate this change from the 2.0.0 branch and open a new PR targeting 2.0.0 instead of main.

The reason is that this notebook explicitly clones/checks out 2.0.0 and depends on the files, configurations, and dependency conventions from that branch. Those are no longer aligned with the current main branch, so targeting main makes the PR base inconsistent with the code the notebook actually runs and would place maintenance of a 2.0-specific workflow on the main line.

Also, main and 2.0.0 have diverged substantially. Simply changing this PR base branch may therefore produce an incorrect or unexpectedly large diff. Please create a fresh branch from 2.0.0, reapply the intended changes there, and submit the replacement PR with 2.0.0 as its base branch. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants