<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 13, 2020 at 10:04 AM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Jose,<br>
<br>
On 10/01/2020 17:33, Jose Valdez wrote:<br>
> Hello,<br>
> <br>
> Regarding this topic and to start to define the python tools that are more appropriate for the RTEMS community python developments, I would like to propose the following tools (to be placed in RTEMS Software Engineering manual):<br>
> <br>
> Python language version: 3.6 (minimum version for Doorstop 2.0.post2)<br>
> Python coding style/standard - Google (as suggested by Gedare)<br>
> Python documentation style - Google docstrings (to be in accordance with coding style. Note it is supported by sphinx)<br>
> Python test approach - unittest (seems to be the standard used by python)<br>
> Python static analysis - pylint (recommended by Google style, see <a href="http://google.github.io/styleguide/pyguide.html" rel="noreferrer" target="_blank">http://google.github.io/styleguide/pyguide.html</a>) and mypy (catch additional errors) Python code coverage - Coverage.py (seems to be the standard used by python)<br>
> Python third party packages - For now we are using: paramiko, pyserial, pexpect, gitpython, but the list is expected to be changed. I think here any third package is allowed, as long as the license of the package complies with RTEMS project license.<br>
<br>
To be future-proof: python3 compatibility would be nearly a must-have<br>
for any new library.<br></blockquote><div><br></div><div>We discussed this somewhere earlier and I thought we decided that if</div><div>it was a core tool required for a "normal user", then it would have to</div><div>be Python 2.x and 3.x compatible. Tools for "requirements user" or</div><div>"pre-qualification user" (pick a name for this role), can be 3.x only </div><div>mainly because there was so much infrastructure required for the</div><div>"requirements user" that already needed Python 3.x.</div><div><br></div><div>I think this discussion should also include "documentation producer"</div><div>because that requires Python 3.x as well.</div><div><br></div><div>We just need to be conscious of the user roles that the tools are</div><div>supporting and justify the minimum. This gives us at least 3 categories</div><div>of tools with potentially different minimum hosting requirements. For</div><div>example, we may not care if a certain set of tools runs on Mingw.</div><div><br></div><div>Obviously documented somewhere.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I don't think that there are heavy license problems. The python packages<br>
are most likely only used in tools. So as long as they are open enough<br>
to use them on all host platforms for all development situations that<br>
shouldn't be a problem. Exception: If the package is used to generate<br>
code with a specific license. That generated code would have to be<br>
compatible with the RTEMS license.<br></blockquote><div><br></div><div>+1 and very much non-viral and no advertising for generated code.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> Please tell me your opinions for each python tool and then we can start to agree on what to use. Note that once this is defined, our Qualification software will comply with the RTEMS community chosen tools.<br>
<br>
If no one objects I would suggest to start documenting them in the RTEMS<br>
Software Engineering manual. A small example project in the rtems-tools<br>
repository that uses the suggested code checkers (meaning: calls them<br>
during a waf build or a special 'waf check' target) would be great too.<br>
That could be used for all future python based tools that are added to<br>
rtems-tools (which includes the whole qualification tools).<br></blockquote><div><br></div><div>Yes. It must be enforced. Whether it is a special step or not is up for discussion.</div><div>My first thought is that a special step is easy to skip.</div><div><br></div><div>Also can "check" be done as a pre-commit hook? </div><div><br></div><div>And when the style is agreed to, should existing code be auto reformatted</div><div>to meet it?</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> Best regards<br>
> <br>
> José<br>
> <br>
> -----Original Message-----<br>
> From: devel [mailto:<a href="mailto:devel-bounces@rtems.org" target="_blank">devel-bounces@rtems.org</a>] On Behalf Of Chris Johns<br>
> Sent: quinta-feira, 9 de janeiro de 2020 20:57<br>
> To: Gedare Bloom; sebastian huber<br>
> Cc: <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> Subject: Re: Requirement Document generator tool<br>
> <br>
> On 10/1/20 4:45 am, Gedare Bloom wrote:<br>
>> On Wed, Jan 8, 2020 at 11:51 PM Sebastian Huber<br>
>> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>>><br>
>>> On 08/01/2020 19:31, Gedare Bloom wrote:<br>
>>>>><br>
>>>>> I agree completely on the proposed approach with Python tools.<br>
>>>>><br>
>>>> Yes. Reading it I'm actually reminded about Google's approach toward<br>
>>>> Python which includes many of the elements mentioned. Although their<br>
>>>> guide is probably more comprehensive and verbose that what we need, it<br>
>>>> might be a useful reference for developing a set of guidelines<br>
>>>> suitable for Python code in RTEMS (mainly, rtems-tools).  Here is a<br>
>>>> link:<br>
>>>> <a href="http://google.github.io/styleguide/pyguide.html" rel="noreferrer" target="_blank">http://google.github.io/styleguide/pyguide.html</a><br>
>>>><br>
>>>> I think most of the existing style has been determined and driving by<br>
>>>> Chris Johns. So I would also give him some credit to develop/approve<br>
>>>> how we plan to use Python at a project level. (**Hands Chris an "RTEMS<br>
>>>> Python Maintainer" hat**);)<br>
>>><br>
>>> I think the Google guide would be a good start. We can always add<br>
>>> project-specific exceptions/clarifications if necessary. My aim is to<br>
>>> use it for new code, e.g. code produced for the pre-qualification<br>
>>> activity. For the code format I strongly want to use a tool for this. I<br>
>>> don't want to spend review time on code formatting issues.<br>
>>><br>
>>> Using standard guidelines makes the RTEMS Project more attractive for<br>
>>> new contributors and GSoC students. I think it increases your job<br>
>>> opportunities if you can refer to a successful GSoC project and it shows<br>
>>> that you used standard engineering practices in the project. This is<br>
>>> usually not something a university education includes.<br>
>>><br>
>> OK, both points make sense. I'd be happy with the Google guide, I hope<br>
>> Chris will comment when he can.<br>
> <br>
> Sorry about the erratic access. I have been knee deep in painting and flooring<br>
> this summer as I avoid any smoke from the fires we are having.<br>
> <br>
> I am fine with using a standard guide however we need to review it and to make<br>
> sure it fits. As an example the C++ guide from Google had some good points as<br>
> well as some parts I did not think offered any value but did create a certain<br>
> level of pain. We should also consider capturing the guide as a public one<br>
> belonging to someone else can and will change and that effects us. I am not sure<br>
> how we could do this.<br>
> <br>
> Chris<br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <br>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax:   +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>