Re: [Buildroot] [PATCH] package/micropython: add support for manifest.py in the configuration

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

Abilio, All,

[Please, don't top-post, but reply in-line]

On 2024-02-11 09:15 -0800, Abilio Marques spake thusly:
> One of the uses of manifest.py is to specify which modules of
> micropython-lib should be frozen within the binary.  For those modules you
> don't need to include the path. e.g.,
> package('os')
> 
> That's the application I'm going for. I know it seems limited but it's
> really useful,

OK, so maybe this can be explained in the help text of the new option,
like:

    Note: in Buildroot, only modules provided with micropython-lib
    can be frozen with a manifest; freezing arbitrary files is not
    supported.

along with a little blurb in the commit log, statng something like;

    We only support freezing of modules from micropython-lib. Freezing
    arbitrary modules would require some handling of absoulte paths, and
    a guarantee that the files be available before micropython is built,
    which is considered a bit too complex; an interested party can
    provide such support in the future.

And thus, would it be possible to sanity-check the manifest to ensure
that it indeed only references modules from icropython-lib, so that
people do not get the impression it works when in fact it does not?

Like, grep that only require(...) are used?

(Note: you mentioned package(...) but that is not limited to files from
micropython-lib; require(...) however is.)

> and probably welcomed by other people using Micropython in
> the next release of Buildroot.

One question I was wondering about: if a module is frozen in the binary,
then it is no longer needed in the filesystem, right? If so, should we
have a way to remove them?

> I have ideas on how to solve the path and dependency order problem while
> still using the "official" manifest.py concept. The biggest challenge is
> that currently there are no other 3rd party Micropython modules available
> for Buildroot, so that makes it all very theoretical. All solutions require
> a bigger amount of work than the one needed for this patch. Also, I would
> like to discuss them before actually presenting a patch that allows 3rd
> party modules to be frozen.

Indeed, without a few actual examples, it's going to be difficult to see
a common pattern and abstract that away. Are there any pulicly
available?

> I always try to go for an incremental approach, where I get the bigger bang
> for the buck. I believe that allowing people to freeze the official
> Micropython modules is already a big step forward. But at the same time,
> I'm new to the Buildroot project, so please advice on the approach.

The incremental path is totally OK; I even prefer it. Of course, any
limitation (such as those we are discussing) should be explained in the
commit log.

Given all the feedback in this thread, can you respin a v2 taking the
comments into account?

As for your ideas for lifting those limitations, you can just explain
them in a reply in this thread. Usually, a patchset doing the job is
also a good first step to start the dicsussion.

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  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot