I think that generating the python code makes the most sense. The body of
the code can still defer to the dynamically generated object, since it's
not available until runtime anyway, but the user no longer has to resort to
using lambdas because of the deferred bindings.
I imagined it would work like a regular module:
>>> import vpp_papi.plugins.map as map
>>> dir(map)
...
>>> help(map)
vppapigen would generate stubs such as:
vpp_papi.plugins.map.py:
def map_add_domain(client_index: u32, context: u32, ip6_prefix:
IPV6Network, ip4_prefix: IPV6Network, ip6_src: IPV6Interface, ea_bits_len :
u8, psid_offset : u8, psid_length : u8, mtu: u16, tag : str ) -> i32:
"""docstring from .api block comment
"""
<return <VppApiDynamicMethodHolder> >
The user, of course, still needs to connect to VPP for their code to run.
but the typedefs could become data classes and the encode/decode methods in
the test code become unnecessary.
vl_api_ip_ecn_t.IP_API_ECN_NONE could become ip_ecn.NONE
The IDE's could then provide type checking and auto completion. (So one
would know that NONE was an option without referring to the sources.)
We would need to play around with it to see how well it works.
On Sat, Nov 14, 2020 at 1:16 PM <otr...@employees.org> wrote:
> Hi Paul,
>
> Picking off one issue at the time.
>
> > Why won't Ole, as maintainer, allow it?
> >
> > The build system uses something called vppapigen to generate the c
> include files and the json files. It could as easily generate static stubs
> so that development with python could be usable without a running vpp
> instance.
>
> I certainly didn't intend for my opinion to come off as a "don't allow".
>
> Initially the Python code was fully generated from vppapigen. With a class
> per .api file and fully formed methods. Later it evolved to dynamically
> create all functions based on the API representations in JSON.
>
> (This latter change made the Python binding independent of VPP version
> which is how it was possible to individually package it and put it on PyPI,
> but lets do that on a separate thread.)
>
> Generating Python code from vppapigen is simple. But just how do you want
> these stubs to look like and how should they be packaged and used?
>
> If I have pushed back on this it's likely more out of ignorance of the
> problem rather than ill will. ;-)
>
> Best regards,
> Ole
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18065): https://lists.fd.io/g/vpp-dev/message/18065
Mute This Topic: https://lists.fd.io/mt/78229638/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
