uPyPi for Thonny: Arduino-like Library Manager for MicroPython

[leezisheng]

Hi everyone 👋,

I'm the author of the uPyPi project (our PyPI-like MicroPython package repository: #18904). Today, I'm excited to share a new tool that brings uPyPi's package management directly into the Thonny IDE: the uPyPi Package Manager Plugin for Thonny!(we will finish all function 2 week later)

✨ What it does

Just like the Arduino Library Manager, this plugin lets you:

• 🔍 Search for MicroPython libraries/drivers on the uPyPi repository (e.g., bh1750, micronumpy)
• 📋 View package metadata: version, author, description, and compatibility info
• ⚡ One-click install: Download the library and automatically copy it to your MicroPython device's /lib folder (no more manual file copying!)
• 🗂️ Manage cached packages: Reuse downloaded libraries without re-downloading

Here's a quick demo of installing the bh1750 light sensor driver:

And searching for micronumpy (a MicroPython numpy-like matrix library):

🎯 Why this matters

MicroPython developers often struggle with manually downloading libraries, copying them to devices, and managing versions. This plugin aims to:

• Lower the barrier to entry for new developers (no more "how do I install a library?" questions)
• Integrate seamlessly with the uPyPi ecosystem (all packages follow standardized package.json metadata)
• Bring the convenience of Arduino-style library management to MicroPython

🤔 Quick question for the community

I have two quick questions to help shape the future of this plugin:

1. What IDE do you use most for MicroPython development?

• Thonny?
• VS Code (with PyMaker/MicroPython extension)?
• Mu Editor?
• Pycharm?
• Other (please specify in comments!)

This feedback will help me prioritize which IDE to support next (e.g., VS Code, Mu) and refine the plugin's core experience.

2. What features would you like to see in this uPyPi-Thonny plugin?
   Some ideas to spark your thoughts:

• One-click library version upgrade/rollback
• Automatic detection of device-compatible library versions (e.g., RP2040/ESP32-specific builds)
• Offline package installation (import local .mpy/.py files)
• Automatic dependency resolution and batch installation
• Custom uPyPi mirror sources (to speed up downloads in regions with poor connectivity)
• One-click uninstall of installed libraries
• Any other features you think would make your MicroPython workflow smoother (please share in comments!)

🔗 Links

• Original uPyPi Repository Discussion: About uPyPI
• uPyPi Platform: https://uypi.net/

Looking forward to your thoughts and feedback! Let's make MicroPython library management as easy as possible together 😊

[Josverl]

• vscode
• pymakr has been unmaintained for years
• most of the features you mention are irrelevant to me, as I find the platform tooling mostly sufficient
• managing dependencies and deployment from a project.toml on the host/repo would be good, though I would not want to depend on any specific extension or ide

I would also appreciate you not multicasting the same message to multiple channels.

[leezisheng]

Hi Josverl,

Thanks so much for taking the time to share your detailed feedback—it means a lot! 🙏

I really appreciate you letting me know you use VS Code, and I’ll note that pymakr is no longer maintained. That’s helpful context for prioritizing future IDE support.

I totally understand that many of the features I mentioned might not be relevant to your workflow, and I agree that managing dependencies via project.toml (without tying to a specific IDE/extension) is a great direction. That’s something we’re eager to explore for uPyPi long-term, so your input here is super valuable.

I also apologize for multicasting the same message across multiple channels—I’m still learning the norms of using Discussions, and I’ll be more careful to avoid this in the future.

Thanks again for your candor and guidance! It helps make uPyPi better for everyone.

[jetpax]

Thonny? Its been holding back the Micropython community for years.

Its impossible to create Micropython apps with 10,000s LOC with current tooling, whereas in fact, MicroPython is SO solid, and asyncio is SO powerful, that it supports that kind of aspiration without breaking a sweat.

Of course, I looked at solutions like ViperIDE, MPYJama, ArduinoLab etc, and they all had issues

Thats why I created ScriptoStudio which is natively Agent enabled, with built in ulab (NumPy), lvgl

supports single stepping debug out of the box,

runs on everything from Desktops to iPads, offline too, and has a built in Hub for scriptOs/skill

Downsides? For now it only supports ESP32, but that has to represent a lot of users, and RP2350 is in the works.

Or just browse the documentation

If like what you see, it's a one click install on your device!

[leezisheng]

Pyco Claw?Hahaha, I just introduced this IDE in my WeChat Official Account article yesterday!

[jetpax]

[leezisheng]

good，look this :jetpax/scriptostudio#3

[peterhinch]

What IDE do you use most for MicroPython development?

None. I use mpremote mount . with a good programmer's editor.

When you're working close to the hardware, IDE's add a layer of complexity and confusion. I've lost count of the queries here which were resolved by the suggestion of quitting Thonny and running the script from a terminal.

[jetpax]

Exactly how I felt Peter, but your asyncio has opened Pandora's box. (Yes its all your fault)

Micropython can now happily run a single app with 40,000 LOC spread over more than 100 modules with mutiple TLS network connections running at the same time reliably, eg pycoclaw (BTW there is zero 'web app' code in there)

When you get to that level, the app itself has a complexity that needs to be managed, which requires some sort of configurator, and with a well defined interface non of the configuration code eg 'web ui' has to live in the app, as it should be.

And then the 'IDE' becomes more than a way to develop code (I actually created a VSCode IDE for webREPLB and never use it) it also becomes a a way to manage an app, and a runtime environment on which to create an app. It becomes what I like to call an IDEE.

Look at any one these apps on Scriptohub as examples

They are all standalone Micropython apps, which are mainly ports of existing (typically Arduino or Platformio projects}, where the Configurator, as well as the IDE, as well as the runtime environment are provided by ScriptoStudio

I should really give a presentation on this at some suitable event, its hard to convey in a github comment :)

And thank you once again Peter for your outstanding contributions to Micropython over the years that make this even possible

[leezisheng]

Really inspired by your discussion! I’ve been working on Python data analysis and computer vision for years, and just started with MicroPython about a year ago. I mainly use PyCharm for development, which feels quite natural for someone familiar with the Python ecosystem. But I also agree that Thonny is perfect for absolute beginners—its visual interface and simple deployment workflow help new developers get started without being overwhelmed by complex setups.
It’s incredible to see how you’ve scaled MicroPython to such large applications and pushed the boundaries of the underlying tooling! Right now I’m mostly working at the application level, leveraging mature drivers and libraries, and I’m still far from being able to contribute to the core code. But I’m slowly digging into low-level details, and I hope I can eventually catch up—even if it’s starting with small docs improvements or tiny tools, I’d love to give back to the community.
Thanks so much for sharing your insights, I’ve learned a ton!

[mattytrentini]

VS Code and sometimes vim. mpremote to manage my connected devices. As well as for personal projects, I use MicroPython commercially for the development of medical devices; we're used to managing large codebases and dependencies.

Thonny is inappropriate for my uses, though I can see it's benefit for beginners. Good luck with your plugin, I wish you success! Though it - nor your package manager - is useful for my purposes.

[mattytrentini]

An obvious missing feature for me is being able to easily view the code from a package link. It's not acceptable to download and then unzip; just provide a link to the code - and I want to be able to browse the history.

Also not tracking a source repository (as PyPI optionally does) is a deal-breaker for me - storing a cache without a link to the original repository would never be acceptable for our uses.

Licenses should be clearly visible from each project page. Ideally, search could filtered by license.

It's not clear which packages work on which port - the 'all' icons are helpful but don't show enough detail. Again, search should be able to filter by port.

The packages.json data is incomplete. It's not clear where the rest of the metadata is stored.

No SHA's. A package manager must have some way of allowing users to validate files in the cache.

On the plus side, there are already some interesting libraries in the index.

Finally, I have issues with the name. I don't speak for Damien or MicroPython in general but "MicroPython Package Index" implies that the package index is supported by the project...which it is not.

[leezisheng]

Thank you so much for your detailed feedback and valuable suggestions! 🙏 All the issues you’ve raised (direct code viewing, source repository tracking, license visibility, port filtering, metadata completeness, SHA checksums, and project name clarity) are critical, and we’ve noted them all down to prioritize improvements and fixes.
We’ll start by implementing core features like direct code browsing, SHA validation, and source repository linking, followed by incremental improvements to license filtering and port compatibility visibility.
Thanks again for your honest input—it’s incredibly valuable for making uPyPI better! Please feel free to share any further thoughts anytime.

[leezisheng]

and Thank you so much for the reminder! We fully agree with your concern about the project naming. We have officially named our project uPyPI and will clearly label it as a community-driven, non-official project to avoid any misunderstanding of official endorsement. Thanks again for your professional advice!

[jetpax]

I like what youve done but packaging the MPY libs into an easy to browse format for humans isnt enough in 2026, IMO.

I loved what @jczic did with https://github.com/jczic/ESP32-MPY-Jama a few years ago, effectively extending libs with a dict to actually make the libs runnable by embedding the script config in his 'JamaFunc'. eg

A big step forward for new users to the platform wanting to re-use community libs, and didnt really get the credit it deserved IMO.

But as we all know, 2026 was the year coding changed forever. Now an agent has to to be able to use the libs easily. And the Agent will be a Claw.

That was the inspiration for my own Script Objects or ScriptO approach which takes @jczic's concept one step further so that an agent can use the library as a skill.

Take for example, an agent wants to play a sound on the hardware. Essentially it needs a skill to do that , which is yes, say , the ES8311 library, yes, the configuration for the platform (eg what JamaFuncs added) , but ALSO agent style prompts in MD so it knows how to use it.

That was the motivation for ScriptoHub

Every "Library Function" is a bundle that can be used by humans AND bots

The code is all there, you can load ScriptOs directly from Scripto Studio , or just 'Download a ZIP' in Scriptohub if you're not ready for that yet :)

[leezisheng]

Thank you so much for the inspiring insights! I fully agree that AI Agents will be the core driving force of programming in 2026, and the direction of making libraries compatible with AI calls is absolutely correct.

However, I have a slightly different perspective on the role of low-level hardware libraries:
Low-level libraries that interact directly with physical hardware (such as sensor drivers, chip peripheral drivers) must go through human+AI joint verification—their stability and compatibility directly affect hardware safety and functional reliability. They cannot be fully generated by AI automatically; developers need to combine actual hardware testing and boundary condition checks to ensure quality.

So I prefer this division of labor:

• Low-level layer: uPyPI focuses on building verified, reliable hardware driver libraries (co-built and verified by humans + AI) as the "basic building blocks" for upper-level applications.
• Application layer: AI Agents concentrate on business logic development, calling these reliable blocks to quickly assemble applications for specific scenarios (e.g., environmental monitoring with temperature/humidity sensors, smart reminders with LEDs).

In essence, everything is an application—the value of low-level hardware libraries ultimately serves upper-level applications, and AI is a tool to make application development more efficient. This clear division of labor ensures both bottom-level stability and agile upper-level innovation.

Thanks again for sharing your thoughts! This perspective has made uPyPI’s positioning much clearer to me. Looking forward to further discussions!