Python Standardization

[Sebastian Huber]

On 22/03/2020 14:33, Gedare Bloom wrote:

> On Sun, Mar 22, 2020 at 7:07 AM Anmol Mishra <anmol.j2020 at gmail.com> wrote:
>> Hello,
>> Since you clarified the motivation for API, I need to ask a few questions which will help me.
>>
>> 1. By API, Do you mean a wrapper or a common access point to test/access all the utilities? If yes, Is REST API is expected like a dashboard?
>>
>> 2. Is there any active API?
>>
>> I know this question may seem to be naive but I need to discuss it and clarification is better than any wrong interpretation. All dev members can help me, I will really appreciate it.
>>
> To get better participation you might want to use a more specific
> subject line and provide some extra context to your question.
>
> The project idea is about defining a uniform/consistent interface for
> using different products located primarily in rtems-tools.git The
> project idea ticket says:
>   * A general RTEMS tool library with a standard API to handle common tasks.
>   * All utilities callable as a function within the API with the tool
> itself being a thin layer.
>   * Testing on all API commands under both Python 2.x and 3.x.
> API is taken as the original meaning of "application programming
> interface" to mean how applications will use the tool library. This
> has nothing to do with web services. I hope that helps with some of
> your confusion.
>
> Many of the "home-grown" RTEMS tools have relatively consistent
> command line interfaces (CLI), but I can't speak to their API; a lot
> of them were designed to be used on the command line, which could also
> be used as an API but it is not efficient because you generally have
> to invoke the tool in a subprocess in such cases.

To identify which modules in rtems-tools are intended to be reusable 
components you can grep for import statements. This shows for example 
that the rtemstoolkit is intended to be reused, e.g.

grep -r --include='*.py' 'import\s' -h . | grep rtems | sort | uniq -c
       5 from rtemstoolkit import check
       1 from rtemstoolkit import config
       4 from rtemstoolkit import configuration
       1 from rtemstoolkit import configuration as configuration_
      30 from rtemstoolkit import error
      15 from rtemstoolkit import execute
       3 from rtemstoolkit import git
       8 from rtemstoolkit import host
      17 from rtemstoolkit import log
       1     from rtemstoolkit import macros
       4 from rtemstoolkit import macros
       2 from rtemstoolkit import mailer
       1     from rtemstoolkit import options
       5 from rtemstoolkit import options
      23 from rtemstoolkit import path
       2 from rtemstoolkit import reraise
       2 from rtemstoolkit import rtems
       4 from rtemstoolkit import stacktraces
       2 from rtemstoolkit import textbox
       1     from rtemstoolkit import version
       9 from rtemstoolkit import version
       2 import rtems

For example rtemstoolkit.error is imported in 30 other modules. This 
looks like a good candidate to get started with unit testing.

Testing the command line tools is also important. We need a good testing 
framework for this. This usually involves setting up a temporary 
directory with some defined content. Starting command line tools as 
subprocesses, capturing the stdout and stderror, inspecting the 
directory, etc.

All this testing work should be accompanied by updates of the Python 
Guidelines.