I personally think it's a bit of a blurry line between considering micropython-lib as more like PyPI or the python standard library.

User Contribution

There's been a few discussions about this lately wrapped up in the manifest and mip development; my understanding is that user submissions of libraries and drivers are ,very welcome and encouraged, however they're still going to need to go through the same PR / code review process as everything else here which is going to slow down the ability for people to release their own code at their own pace, with the trade-off being hopefully higher standards and quality of code released.

Alternatively there's a plan to be able to directly specify your own GitHub repo (with same structure as individual packages here) in manifests / mip to directly release your own libraries without them going via here - this is more like the PyPI alternative.

Package compatibility

This is certainly a complicated topic. I can see there's going to be need to declare compatibility for particular packages in some way; certainly dynamic native module for instance will often only support a subset of ports, and even plenty of pure python ones may use chip specific features like the Pico PIO.

However I don't know that board compatibility makes sense? Most libraries / drivers should work on any board on a compatible port & hardware? If we're taking about board specific code that configures other drivers etc that should live in the board folder (in micropython repo) rather than here.

Thanks @roaldarbol great question.

TL;DR: Is micropython-lib aiming at becoming the PyPi of Micropython?

Yes. Absolutely.

I made a first step PR last week to start updating the README etc to make some of this more clear. #576

Some extra historical context: #506 (and significantly more discussion at the companion main-repo PR here: micropython/micropython#8914 ). There are some examples there of other scenarios we want to support.

One feature in particular is the mpremote support for using manifests directly (i.e. "app manifests"). Also linking this to the "mapfs" feature (micropython/micropython#8381) which allows "dynamic freezing" (i.e. all the benefits of freezing without haivng to recompile or re-deploy the firmware). See for example the results I posted here micropython/micropython#8426 (comment) -- you can deploy entire large app as a mapfs in 3 seconds.

In the process that led to writing mip and the "new" way that micropython-lib works, I spent a lot of time evaluating how we previously used PyPI (via upip) etc. Although obviously I love PyPI and pip etc when working with CPython, there are a few things that just made PyPI not quite right for us, not limited to:

• We need to support a few different ways of consuming a package. On-device, via tools (e.g. mpremote), and via build (i.e. freezing) that have quite different requirements. This gets even more interesting when you consider other types of package (e.g. dynamic c modules, etc).
• The PyPI namespace is global. Identifying micropython packages isn't easy, my experience (and the comments we hear in the forums and here reflect this too) was that installing a given package was unlikely to "just work".
• We want to support installing bytecode-compiled packages. Doing that with PyPI was difficult and puts a lot more burden on the package maintainer.
• MicroPython is run by a small team and we want to be responsible for as little "online infrastructure" as possible. (i.e. leaning on GitHub and static content serving wherever possible).

This hasn't been widely advertised, but we also publish an index.json of all micropython-lib packages at https://micropython.org/pi/v2/index.json

open to user contributions like PyPi

Yes! There are two main parts to this.

1. Someone writes a library that they want to maintain and own (i.e. in their own github repo), but they want the "package index" functionality and convenience of just being able to tell their users mip.install("foo").

We don't currently support this, but I'm working on it at the moment. See miguelgrinberg/microdot#67 for a conversation I had with the microdot maintainer.

(I haven't quite figured out all the details, but the idea is that we want to support third-party repos for on-device, mpremote, and freezing as if they were "first-party", with as little burden on the package maintainer as possible, e.g. to push new versions etc).

2. Someone writes a thing that does what they need and will likely be useful to other people but they have no interest in maintaining it. I think drivers are a great example of this. The CPython / PyPI ecosystem doesn't really have an equivalent here that I know of, but I see these as exactly the sort of thing that someone could contribute to micropython-lib.
   This is the part that I'm the most excited about -- there's a huge wealth of useful MicroPython code out there that just needs somewhere to live. Also by putting it into micropython-lib there's an opportunity for review/feedback from maintainers etc... although I'm cognisant of the load that could put on us! The bar isn't as high as the main repo though - the priority in micropython-lib is making useful things available.

custom firmware, boards, etc.

This is all slightly more complicated. The Pimoroni case in particular where they want to not only freeze Python code, but also a lot of extra C code. This is definitely on our radar, and we're seeing this across multiple vendors (of various sizes!), and if we're going to be the official source of board firmware, then we need to support it.

versioning

mip (and the related supporting infrastructure) lets packages define a version. When you install a package you can optionally specify a version (and implicity the bytecode version of the device you're installing to). Packages bundle their dependencies, so you always get dependencies at the version that matches the desired package. Installing "latest" (default) gets you the latest of all dependencies.

Note that we expressly do not support the scenario where two packages, A, B, depend on different versions of the same shared dependency, C -- you will end up with C at whichever version was pulled in by whichever of A and B you installed most recently. i.e. this means that installing B can break A if it downgrades C. (Yes, this is very simplistic, and there are lots of incremental improvements we can make by adding varying levels of extra metadata onto the board during the installation process).

compatibility

This is also on our radar. I'm not terribly keen on having packages list boards specifically, but definitely having a way to say "will this package run on my device" is important. i.e. some sort of GUI tool should be able to just show packages that will work on the currently connected device.

The other side of this is generally defining a set of "compatible" APIs that packages can use and then expect to work on "most" devices.

Happy to discuss more here, and also on discord -- https://micropython.org/discord