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.
Damien
Site Admin
Posts: 614
Joined: Mon Dec 09, 2013 5:02 pm

Re: State of micropython-lib?

Post by Damien » Wed Feb 07, 2018 7:32 am

Hello everyone,

Thanks to those who raised their concerns over the recent forking of MicroPython and the library. I agree the current state is confusing and explanations are needed.

Without going into specifics, Paul (aka pfalcon) can oftentimes demonstrate inappropriate behaviour in discussions. For those who have been with the project for a while, and who participate actively on GitHub discussing PRs and issues, they will most likely have engaged with Paul at some point and understand the situation.

Paul's behaviour online reached a point towards the end of 2017 where, regretfully, I felt that he was doing more harm than good to the project. If you are interested you can read for example this post: https://mail.python.org/pipermail/pytho ... 50383.html

Not withstanding his contributions, and given his behaviour, I took the difficult decision to ask him to step down as maintainer of the project, and I eventually removed his push-rights to the main MicroPython repository.

I hope it is appreciated that we can discuss this sensitive issue in the open in a fair and reasonable way. That's the nature of true open source development: that not only the good but also the not-so-good events happen out in the open. Coming through such an event, MicroPython will be all the stronger for it.

To make it clear: https://micropython.org, https://forum.micropython.org, https://docs.micropython.org and https://store.micropython.org are all the official sites of The MicroPython Project and are run by the company George Robotics. The official source of the code is found at https://github.com/micropython/micropython which is the official master version. All PRs and issues should be directed to that repository

As for the libraries: https://github.com/micropython/micropython-lib will continue to be the location of the official libraries supported by the official master version of MicroPython. For PRs and issues associated with the libraries please use that repository.

As for libraries on PyPI: this will be sorted out shortly.

As for Paul's fork of MicroPython: if he insists to develop and promote his fork he should, as was already stated in this thread, rename it to something other than "MicroPython" in order to avoid confusion among users.

Let me also take this opportunity to again thank everyone who is involved with the project -- Paul included -- for their contributions big and small, whether it be participating on the forum, discussing things on GitHub, bringing MicroPython to a wider audience through outreach, or contributing code. I very much appreciate everything that is done and everyday I am amazed at how far MicroPython has come, and look forward to seeing it flourish as much as possible, in all manner of domains.

Damien.

pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: State of micropython-lib?

Post by pfalcon » Wed Feb 07, 2018 10:14 am

Without going into specifics, Paul (aka pfalcon) can oftentimes demonstrate inappropriate behaviour in discussions.
Please don't overdramatize it. Maybe, "sometimes". So, I'm the guy who often rushed to answer questions (my post count here is twice as yours), I'm the guy who merged good pull requests in 5 mins, I'm the guy who did that when you didn't do that for month(s). Also, maybe George Robotics has you on payroll so you can keep silence for month(s) and batch up replies later, but I'm doing all that support on my own free time, whenever I have a chance, which oftentimes necessitates terseness. Beyond that, it's respectful for contributors to make due diligence when contributing. Many people don't know that, and are given hints and suggestions, but some people aren't ready to accept that. As communication volume grows, such cases unfortunately happen.

Paul's behaviour online reached a point towards the end of 2017 where, regretfully, I felt that he was doing more harm than good to the project. If you are interested you can read for example this post: https://mail.python.org/pipermail/pytho ... 50383.html
And what can we see there? A sensitive dude as me sees the message bordering on the violation of the Python Software Foundation Code of Conduct, where one of CPython developers tries to shame and hush into silence a contributors to the discussion. That developer is known for abrupt, if not harsh comments, bordering on going personal, to other contributors too, for example: https://mail.python.org/pipermail/pytho ... 51702.html . It goes beyond that, the author of Nuitka, an alternative Python compiler once had a blog dedicated to that individual titled "Dictator". You would need to trust my word for it, because it was since removed (the project sought to receive PSF stipend). Beyond that, half of the Python community condemn that individual for what he did on the whole Python2-vs-Python3 matter. So, Damien, if you're setting a strawman case based on the fact that aforementioned individual flamed someone, that's pretty boring news. It's human communication, it happens.

To make it clear: https://micropython.org, https://forum.micropython.org, https://docs.micropython.org and https://store.micropython.org are all the official sites of The MicroPython Project and are run by the company George Robotics. The official source of the code is found at https://github.com/micropython/micropython which is the official master version. All PRs and issues should be directed to that repository
Summary for the less avid readers among us: it's all about business. George Robotics failed to set up well-defined, comfortable grounds for large-scale contribution to the project, as I for example spent not-trivial efforts to discuss, argue, and defend the direction projects takes (== my effort investment into it), with a party on the other side oftentimes being "wanna-wanna-wanna" or "gimme-gimme-gimme". It failed despite proposals to do so (neither specific proposals nor alternatives were implemented). Which either shows poor leadership (which is hard to believe), or raises all those thoughts of "letting to work... so far" and "free grunt". Then at one point, George Robotics thought "enough of free labor, let's take a difficult decision".
As for the libraries: https://github.com/micropython/micropython-lib will continue to be the location of the official libraries supported by the official master version of MicroPython. For PRs and issues associated with the libraries please use that repository.

As for libraries on PyPI: this will be sorted out shortly.
So what do you do? Come to Guido and crowd and ask to take away my project from behind my back?
As for Paul's fork of MicroPython: if he insists to develop and promote his fork he should, as was already stated in this thread, rename it to something other than "MicroPython" in order to avoid confusion among users.
Sure, I definitely appreciate the suggestion and will keep it in mind. I don't "insist", I'm interested in the development so far, and taking only necessary steps to alleviate the matters you've started. For example, if some feature waited in the review for long time, and didn't get any response, and I now merge it into my fork, and make micropython-lib changes using them, I tell the people about the fact. Indeed, that's the least I can do (stopping development is not an option, I've invested 4 years into it, and all these 4 years promoted and contributed the mainline, including the last year on "free grunt" impressions).

Overall, I guess I'd follow an existing process in MicroPython community: my fork is just one of 1500 other forks. Some forks are long-living, like stijn's (@stinos') fork mentioned here, some seem to be getting more traction than mainline in some areas, like Loboris' fork for ESP32 (and before that there was a guy with his ESP8266 fork, and there're countless guys with other hardware-specific forks). Again, for 4 years I avoided this hilarious situation, by contributing to the mainline. Including last year when my org proposals were turned down. Including last month when I was asked to shut up.
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

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

Re: State of micropython-lib?

Post by cefn » Wed Feb 07, 2018 10:50 am

To make a concrete proposal re:PyPi/upip

If for the future, Paul was to develop more capable versions of packages in micropython-lib, but which depended on changes not yet in micropython/micropython then if he were to upload these packages as e.g. micropfalcon-packagename then the name collision has gone, the fear of users hitting broken libraries by making everyday use of upip with the micropython- prefix would be averted, but also those wishing to adopt Paul's bleeding edge capabilities would know they should get/build the corresponding image to support those further capabilities from pfalcon/micropython. His contribution can continue to be highly impactful if/when changes are pulled into micropython/micropython or micropython/micropython-lib with thanks.

How does that sound? I hope I have all the names right and Paul doesn't mind the suggestion.

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

Re: State of micropython-lib?

Post by tuupola » Wed Feb 07, 2018 12:28 pm

My only issue of pfalcon/micropython-lib being the official standard library repo would be if it depends on non-official fork of MicroPython. It would be too confusing. If it is usable with vanilla MicroPython everything is fine. Maybe release those packages needing special version of MicroPython as separate package?

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

Re: State of micropython-lib?

Post by tuupola » Wed Feb 07, 2018 12:36 pm

Damien wrote:
Wed Feb 07, 2018 7:32 am
Paul's behaviour online reached a point towards the end of 2017 where, regretfully, I felt that he was doing more harm than good to the project. If you are interested you can read for example this post: https://mail.python.org/pipermail/pytho ... 50383.html
Read through the November archives. Quite frankly I see only knee-jerk reaction of Guido to discussion on which he and Paul have different points of view and Paul has good reasoning behind his.

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

Re: State of micropython-lib?

Post by pythoncoder » Thu Feb 08, 2018 9:34 am

tuupola wrote:
Wed Feb 07, 2018 12:28 pm
My only issue of pfalcon/micropython-lib being the official standard library repo would be if it depends on non-official fork of MicroPython. It would be too confusing...
The new version of uasyncio (V2) does require the non-official fork. I don't know the status of other library modules.
Peter Hinch

LisaM
Posts: 19
Joined: Tue Nov 07, 2017 6:11 pm

Re: State of micropython-lib?

Post by LisaM » Tue Mar 27, 2018 8:04 pm

Roberthh wrote:
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.
I agree, i'm trying to bring out a MAJOR application on micropython and the last thing i want is to have a fragmented micropython. That said, i will focus on the official micropython repository which is the gold standard.
If your fork is breaking compatibility with the gold standard, i will not bring out the application on that fork (like Loboris, since it isn't fully compatible with micropython-lib/uasyncio). I was considering Loboris since it's using PSRam which is very usefull, don't care much about the other features.
Last edited by LisaM on Tue Mar 27, 2018 8:26 pm, edited 1 time in total.

kevinkk525
Posts: 436
Joined: Sat Feb 03, 2018 7:02 pm

Re: State of micropython-lib?

Post by kevinkk525 » Tue Mar 27, 2018 8:22 pm

You do not understand that only pfalcon supports his V2.0, all others are still below that version.
pythoncoder wrote:
Thu Feb 08, 2018 9:34 am
The new version of uasyncio (V2) does require the non-official fork. I don't know the status of other library modules.
So loboris fork is still fine, theoretically. It has to pass some stability tests for asyncio as not many use it on his fork and it's only working since about a month when we discovered a few bugs in utime(q) modules.

LisaM
Posts: 19
Joined: Tue Nov 07, 2017 6:11 pm

Re: State of micropython-lib?

Post by LisaM » Tue Mar 27, 2018 8:45 pm

kevinkk525 wrote:
Tue Mar 27, 2018 8:22 pm
You do not understand that only pfalcon supports his V2.0, all others are still below that version.
pythoncoder wrote:
Thu Feb 08, 2018 9:34 am
The new version of uasyncio (V2) does require the non-official fork. I don't know the status of other library modules.
So loboris fork is still fine, theoretically. It has to pass some stability tests for asyncio as not many use it on his fork and it's only working since about a month when we discovered a few bugs in utime(q) modules.
I don't want to support a non-standard library, like asyncio v2. We support ESP8266, ESP32, STM32F405 and Orange/Raspberry PI as micropython platform using a single code base for our app (uPyEasy). This is difficult enough, even with the standard micropython version.
Anything that doesn't support the standard micropython version goes out the door, we don't have the time or resources to do otherwise.

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

Re: State of micropython-lib?

Post by pythoncoder » Wed Mar 28, 2018 6:09 am

Some quotes of my comments are now out of date. This is the current state re uasyncio.

The official repository now supports uasyncio V2.

The Loboris port lags a little behind the official repo, but is planned to be synchronised at the end of this month (March) reference. Until then, usayncio V2 is not supported.
Peter Hinch

Post Reply