datetime not working out of the box

[stijn]

The question that I have is how should I approach the requirement for the fixes? Should I work to push them into micropython-lib or should I keep my custom version of datetime that is 99.99 % identical?

With the fuzz above I almost forgot to answer the actual question The nice thing to do here is both. Either add a comment on the PR you mention or create a new one. Even if it does not get merged anytime soon, at least the fix is out there which is helpful for others. And you keep your fork and use that to work from. Also out of interest: do the tests pass? I keep similar fixes in my fork but test_datetime doesn't pass all tests for MicroPython nor for CPython

[johanson]

I will check if a consolidated PR exists for all these fixes and may open one in near future if one isn't already on Github. I did not get to run any tests as I was happy with the fixes and continued work on my project that uses datetime. I will run tests when I work on the PR.

[stijn]

It needs to be made read-only

As it happens there's an interesting related discussion today on HN: https://news.ycombinator.com/item?id=27274056. While archiving a repository isn't a subject, it is about related measures like automatically closing stale isses, locking issues etc. Main topic is a 21-year old bug was fixed, sheds a different light on some things

[kevinkk525]

Personally I always steer clear of unmaintained repositories (like micropython-lib) because often I just end up wasting lots of time with code that may or may not work, may or may not have multiple PRs open that I have to check and merge myself to get a working code, may have multiple issues open that nobody cares about, may or may not be outdated and not even work on current micropython anymore, etc.. It's like finding and old car in the woods with hundreds of notes on it about issues and ways to fix some of its problems but with no owner around who could answer questions about it. So you can either get in and try to get it working, or you strip it for parts that might still work but either way, it's more like a gamble and it definitely takes time and doesn't put a good look on the maintainer (which is micropython and therefore on the whole micropython project).
So if I see a repository with it last commit a year ago and multiple issues and PRs open, I typically don't even bother checking it out as there are likely hundreds of bugs that nobody will ever fix. (micropython-lib however consists of multiple different projects within the repository so many of those will still work fine and not require any new commits even after 3 years, so it's a bit different. This was just a general description of my view on repositories).

Even though read-only sounds rather drastic, the state of the current micropython-lib repository doesn't put a good light on anyone. New people will have a hard time figuring out which modules work, which have bugs, which are outdated etc and might get unneccessarily frustrated over it. Others eagerly try to fix bugs just to find out that nobody actually cares about their contribution..
I'd suggest at least removing everything that doesn't work or isn't needed anymore (like uasyncio) and updating the README about the current state of the repository and some packages. Or maybe break out some modules into separate repositories with someone who will maintain it and check PRs etc.

[mattyt]

I'm aware that micropython-lib has been languishing - and so are Damien and Jim. It's still on their radar though and they're aware that it's a growing problem. I hope we'll start to see some activity there soon and I'm going to do what I can to help out...

The intent to rejuvenate micropython-lib is there (see PR376), it's just been a lack of time.

Ideally, I'd like to reign in the forks (though I understand they're necessary while there's no activity!) and merge in as much as possible (especially SpotlightKid's excellent work). There needs to be a little bit of guidance put in place too - for example, PR's are more likely to be merged if there are tests, CPython compatibility, documentation and are PyPi publishable.

So I'd suggest - please! - continue to raise PR's.

[stijn]

It finally happened https://github.com/micropython/micropyt ... its/master

[kevinkk525]

Very nice. It's a good start. Looks a lot better now.

[mattyt]

It finally happened https://github.com/micropython/micropyt ... its/master

Dammit, you beat me to it

[johanson]

Having seen positive signs of activity in the micropython-lib repo I've submitted two PRs. Let's see how that goes.