README issues
paul-hammant opened this issue · comments
-
Section starting "On top of it" has two "On top of it" sentences, and otherwise suffers from long sentence syndrome.
-
Source tree layout section says "version of MicroPython" and "MicroPython port" three times. Wait .. that is / isn't pycopy? Or maybe it's legacy language in the README, or maybe it's extra somehow and could be removed from the repo, and be in a separate (new) repo.
-
FAQ sections needed:
3.1 Win/Lin/Mac/iOS/Android/ChromeOS/Fucsia compatibility?
3.2 Which package managers for pips/eggs? And compatibility with pips/eggs from MicroPython-land?
Thanks for the report. I'll process it in detail going forward, just some quick responses now:
Source tree layout section says "version of MicroPython" and "MicroPython port" three times. Wait .. that is / isn't pycopy?
README starts with:
Pycopy is based on MicroPython. Name "Pycopy" and "MicroPython" is used interchangeably below.
Win/Lin/Mac/iOS/Android/ChromeOS/Fucsia compatibility?
Pycopy is first of all a language implementation. Build it for your system, and it will run. Ports to various systems are important, but somewhat secondary goal, simply because it's not possible to maintain ports too all possible systems within one project. Hence, the goal is to keep the project minimal, so porting it to other systems (by 3rd parties) is easy enough. Anyway, of your list, ports to Win/Lin/Mac/Android exist in the main repo.
3.2 Which package managers for pips/eggs?
README has:
Unix version comes with a builtin package manager called upip, e.g.:
$ ./pycopy -m upip install pycopy-pystone
And compatibility with pips/eggs from MicroPython-land?
All I can say is that yours truly is the primary designer and implementor of MicroPython packaging infrastructure, consequently... However, I don't use MicroPython myself any longer. And of course, I can't vouch anything for packages made by 3rd parties.
Cool thanks for responses. I'm going to rashly suggest that you should not use "Pycopy" and "MicroPython" interchangeably as there will be a greater bounce rate for visitors coming to the GH project as it is now.
Add "Win/Lin/Mac/Android compatible" as a FAQ item?
Apologies for missing the upip note - add "has own package manager" to the FAQ?
I'm going to rashly suggest that you should not use "Pycopy" and "MicroPython" interchangeably as there will be a greater bounce rate for visitors coming to the GH project as it is now.
While I'd think I understand your concern, to avoid guesswork and personal biases, could you elaborate while it would lead to "greater bounce rate"?
Looking into further issues reported:
Section starting "On top of it" has two "On top of it" sentences,
Well, suppose you had a need to put 3 cubes on top of each other? How'd you describe doing that? I would do it in following way: "Put cube 1. Put cube 2 on top of cube 1. Put cub3 on top of cube 2." Look, there're two "on top of"! Yes, and that's intended, it describes exactly what happens. The same happens in that section - it says that it's "multi-level project", and that shows how each level is built on top of each other. Sure, an example of rewriting it is welcome, but no warranty I would like it.
and otherwise suffers from long sentence syndrome.
Easy to believe! But oftentimes, the choice is between short sentences providing oversimplified information, or long, but providing the real information. Oops, a choice. Again, specific rewriting suggestions are welcome, but deciding between them may require A/B testing on focus groups, oops.
Add "Win/Lin/Mac/Android compatible" as a FAQ item?
The problem is that there's no "FAQ", there's only "fork FAQ", which explains why the project was forked from MicroPython. Adding "Win/Lin/Mac/Android compatible" there would lead to confusion, as Pycopy is in no way differs in that regard from upstream. And it's not my intention to confuse the users.
But I got the point - people want to know where Pycopy runs, and the list of target systems in the "Source tree layout" section doesn't ring enough bell. Ok, I've added a paragraph on that to the intro section of the README.
The general issue here is the belief that that the more is written, the more people will read and will know. The truth is the opposite - due to "TL;DR" effect, the more written, the less (at least in relative terms) will be read. And the contents of README is already carefully optimized since 5 years of MicroPython time, and it's not easy to "improve" it.
Again, thanks for feedback!