State of MicroPython universe (was: of micropython-lib?)

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
User avatar
tuupola
Posts: 54
Joined: Sun Sep 17, 2017 12:10 am
Contact:

State of MicroPython universe (was: of micropython-lib?)

Post by tuupola » Sun Feb 04, 2018 12:51 pm

All these different forks and versions of MicroPython and libs is getting quite confusing.
Last edited by pfalcon on Sat Dec 01, 2018 11:52 am, edited 1 time in total.
Reason: Change topic title

User avatar
tuupola
Posts: 54
Joined: Sun Sep 17, 2017 12:10 am
Contact:

State of micropython-lib?

Post by tuupola » Sun Feb 04, 2018 1:16 pm

After following MicroPython for a while, the habit seems to be developers to make forks instead of sending PRs. The situation gets quite confusing when there is x version of I2C drivers for y. Currently there seems to be similar situation with the standard library. There is the micropython/micropython-lib and there also is pfalcon/micropython-lib.

This raises few questions. Which one is the official? From which one do the PyPI packages get updated from? If I was to contribute to MicroPython project where should I send PRs?

There is a forum post which suggests pfalcon/micropython-lib is the official one. Same forum post also says some of the code will not work with the official MicroPython firmware.
pfalcon wrote:
Sun Jan 07, 2018 2:24 pm
The master repository of micropython-lib is now at https://github.com/pfalcon/micropython-lib . Some modules also require my fork of MicroPython, https://github.com/pfalcon/micropython , and there will be more such modules in the future. Majority of modules of course remain compatible with the upstream MicroPython.
I can understand why MicroPython implementations between boards might not be 100% compatible. However having different implementations of standard library will be PITA for all. Goal should be to have reusable code and not to depend on a specific fork of the standard library nor specific fork of the firmware.

SpotlightKid
Posts: 463
Joined: Wed Apr 08, 2015 5:19 am

Re: uasyncio - asyncio-like cooperative multitasking framework for uPy

Post by SpotlightKid » Sun Feb 04, 2018 4:42 pm

I agree. I think that when a project is forked and it looks like the fork is going to be there to stay, it's time to think about a name change for the fork.

cefn
Posts: 230
Joined: Tue Aug 09, 2016 10:58 am

Re: State of micropython-lib?

Post by cefn » Mon Feb 05, 2018 12:12 am

This is how I understood that discussion. It's just my viewpoint and I have no insider knowledge.

Assuming there's a close coupling between the micropython 'kernel' and some emerging library capabilities (structured around uasyncio perhaps) then there's no way to avoid there being a dependency on newer-than-stable capabilities, meaning if you want to adopt those libraries, then you will have to run a correspondingly bleeding-edge image on your board and they just won't work with current stable.

I interpret @pfalcon's comment that there will continue to be a majority of micropython-lib which should run everywhere (because it doesn't have this coupling) but that there will be some unavoidably WITH this close coupling. The alternative is not to distribute emerging library capabilities through micropython-lib and upip, because of incompatibility with current official micropython which would be a shame.

My expectation is that features arising in the more bleeding-edge builds would eventually arrive in micropython official but that will always depend if everyone wants to go in the same direction. In some ways, having the forked micropython builds (and experimental libraries) out there is a good way for everyone to figure out the direction, though.

As regards your question of PRs and issues, I believe it would make sense for issues common to a bleeding-edge image AND the stable image to be reported against stable. However, if you are exploring the more bleeding-edge capabilities, of course reporting against stable wouldn't make sense.

Perhaps someone could weigh in with a good description of how we should refer to the various versions, and if there is a notion of stable vs. next that we might loosely rely on, or if it's equally likely that @pfalcon's micropython version never gets rolled into stable.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: State of micropython-lib?

Post by pythoncoder » Mon Feb 05, 2018 5:32 am

I'm hoping for a definitive statement from @Damien.
Peter Hinch
Index to my micropython libraries.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: uasyncio - asyncio-like cooperative multitasking framework for uPy

Post by pythoncoder » Mon Feb 05, 2018 5:45 am

Agreed. And the PyPi repositories should be separated too.
Peter Hinch
Index to my micropython libraries.

User avatar
tuupola
Posts: 54
Joined: Sun Sep 17, 2017 12:10 am
Contact:

Re: State of micropython-lib?

Post by tuupola » Mon Feb 05, 2018 6:18 am

If this is a case of core developers not getting along anymore then yeah that happens. Best thing would be to fix whatever disagreement there is. If not possible then at least make a clear distinction between the projects. Since docs suggest pfalcon/micropython is also called pycopy standard library for this fork could be called pycopy-lib.

stijn
Posts: 735
Joined: Thu Apr 24, 2014 9:13 am

Re: State of micropython-lib?

Post by stijn » Mon Feb 05, 2018 9:17 am

'pycopy' merely looks like it's the location (as in, internet address) of the docs, the thing is still called 'micropython'. If we all start renaming our forks things will get way more confusing then they are now, I think. E.g. I could just check the differences between pfalcon and main forks by simply changing 'micropython' to 'pfalcon' in the address, pretty convenient. And looking at the differences: pfaclon's adds a bunch of extra functionality rebased on top of (roughly) the latest master of the main fork. And the readme mentions that though it could be more clear I guess. Pretty standard workflow, there's a ton of projects working like that.
make forks instead of sending PRs
That is not very accurate, it's not one or the other, they go hand in hand. You create a fork with the intent of being able to submit PRs, that's how github works best. If that PR is merged you sync your fork with the upstream again.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: State of micropython-lib?

Post by pythoncoder » Mon Feb 05, 2018 10:08 am

It may be clear to seasoned Git users. But a beginner having bought a Pyboard will install the latest firmware from @Damien's site. They will then get libraries from PyPI.

Under the current regime that may fail. When I looked recently the sources at PyPI corresponded with the @pfalcon fork. By his own recommendation this library version requires firmware from his fork. So the new user finds that things break and without trawling docs and forum bafflement will ensue. Supporting such users in here will become that much harder.

In practice as time progresses forks tend to diverge ever more from upstream, so this problem is likely to get worse.

If things can't be patched up I think a complete break as per Pycom and CircuitPython - though deeply regrettable - is clearest for users to understand. That way users can expect libraries and firmware to correspond. And support queries can be directed to the correct authority/forum.

My personal perspective as a user of ~3.5 years standing is that the current situation is untenable. I'm a patient guy and will wait a long time for the situation to be resolved and clarified. But if the current muddle persists indefinitely I may question my continued involvement.
Peter Hinch
Index to my micropython libraries.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: State of micropython-lib?

Post by Roberthh » Mon Feb 05, 2018 10:39 am

I was kind of disappointed by Paul's indication of an own fork. I do not want to deal with many forks with more or less subtle differences. I would prefer if Paul and Damien could get together again on a single Micorpython.org and micropython-lib version.

Post Reply