Re: [Buildroot] [PATCH] package/micropython: make use of recent micropython-lib

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Abilio, All,

On 2024-01-28 12:56 -0800, Abilio Marques spake thusly:
> The micropython project does not attempt to perform any kind of bootstrapping
> during its build process. It relies on cpython for building, testing, and also
> for host tools (mostly used with microcontrollers). So for building
> host-micropython, we would still need cpython. For example, the tools used for
> processing manifest files (tools/makemanifest.py, tools/manifestfile.py) are
> definitely not micropython compatible, at least not without the libraries I'm
> actually trying to collect ;). Another hint, the scripts are crowned with a
> python3 shebang.

So we can't use host-micropython to build micropython; that's OK. Let's
forget about that idea, then.

> If we want to do this using micropython code, it also requires re-implementing
> a lot of the functionality I'm currently borrowing from manifestfile.py . In my
> mind, that also means a lot more chances of requiring maintenance it in case
> the upstream changes the way they do things.

Yes, that was just a long shot. Let's drop the idea of using micropython
to build itself, then. Thanks for the feedback.

> As far as I know, to generate the mpy files, only 'mpy-cross' is needed. During
> the target build process, this is built first (but runs on host). It will be
> used to freeze modules within the micropython binary (currently asyncio is one
> example). Internally, it makes use of the same "manifestfile.py" I'm borrowing
> from. Creating a manifest is the route I plan to use to add support for
> freezing packages within the binary. The problem is, you still need to collect
> the list of all the packages available in the micropython-lib repo.
> 
> To avoid the import trick, I could also:
> - Add the path to micropython/tools into the PYTHONPATH at the time of calling
> the script.
> - Copy my script into the tools directory and run it from there during build.
> 
> Base on all of the above, I fail to see positive benefits of writing this
> script so it runs in micropython. Could you please indicate what advantages do
> you see?

If there was host-micropython installed, then I would expect you could
write your script something along the lines of;

    #!/usr/bin/env micropython

    import argparse
    import manifestfile  # Import automatically rather than manually
    [...]

    def main():
        # Here you don't need to inmport it, as it's imported
        # by the python interpreter above.
        manifest = manifestfile.ManifestFile(yadyada)

        [...]

This is also a classic eat-your-own-dog-food situation, where using
one's own tool to manage one's tool, is better than using a third-party
tool. ;-)

Of course, I'd accept the fact that this is not possible if micropython
is not up to the task.

> Thanks for all your comments, they make for great improvements, so I will
> update the patch. This is my first time using git send-mail, and I wouldn't
> know how to make the updated version part of this chain. Do you have any
> suggestions?

I personally prefer a new iteration not be threaded to the previous one,
but be sure to label it 'v2'. Otherwise, you should be able to use
--in-reply-to=MESSAGE_ID.

Regards,
Yann E. MORIN.

> Kind regards,
> Abilio Marques
> 
> 
> On Sun, Jan 28, 2024 at 12:09 PM Yann E. MORIN <[1]yann.morin.1998@free.fr>
> wrote:
> 
>     Chris, All,
> 
>     On 2024-01-29 07:58 +1300, Chris Packham spake thusly:
>     > On Mon, 29 Jan 2024, 7:30 am Abilio Marques, <[1][2]abiliojr@gmail.com>
>     wrote:
>     [--SNIP--]
>     >     This commit also ensures that the libraries in micropython-lib will
>     >     be updated together with newer versions of micropython.
>     [--SNIP--]
>     > One thought I had was to build micropython as a host package and use that
>     to
>     > install the libs into the target rootfs.
> 
>     Yes, this is also my opinion: use host-micropython, if possible.
> 
>     I see that micropython already depends on host-python3, though. Would
>     host-micropython be sufficient in lieu of host-python3, to build target
>     micropython?
> 
>     And would host-python3 be needed to build host-micropython? Or can we
>     get along with just the system python3? If we can use the system pytho,
>     then we can make the dependency on BR2_PYTHON3_HOST_DEPENDENCY rather
>     than hard-code host-python3.
> 
>     Regards,
>     Yann E. MORIN.
> 
>     --
>     .-----------------.--------------------.------------------.--------------------.
>     |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics'
>     conspiracy: |
>     | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___           
>        |
>     | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is
>     no  |
>     | [3]http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v 
>      conspiracy.  |
>     '------------------------------^-------^------------------^
>     --------------------'
> 
> 
> References:
> 
> [1] mailto:yann.morin.1998@free.fr
> [2] mailto:abiliojr@gmail.com
> [3] http://ymorin.is-a-geek.org/

> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot


-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot