Pyuavcan -> Nunavut migration?

[scottdixon]

I believe this is in line with what we discussed but I’m wondering if you are ready to do this:

https://github.com/thirtytwobits/nunavut/tree/milestone/0.1.5

You’ll notice I’ve copied all the pyuavcan jinja over into Nunavut in this branch. My next move is to translate your excellent work into C++.

[pavel.kirienko]

This is a bit sooner than I expected. The change is welcome but there is a minor problem to be addressed: the code generated by PyUAVCAN requires a few definitions from pyuavcan.dsdl. If we’re moving the code generator into Nunavut, we should move the support library there as well. Particularly, the following definitions are relied upon by the generated code:

• pyuavcan.dsdl.CompositeObject
• pyuavcan.dsdl.ServiceObject
• pyuavcan.dsdl.FixedPortObject
• pyuavcan.dsdl.FixedPortCompositeObject
• pyuavcan.dsdl.FixedPortServiceObject
• pyuavcan.dsdl._serialized_representation.Serializer
• pyuavcan.dsdl._serialized_representation.Deserializer

I don’t think publishing a yet another package to PyPI containing the support library is reasonable. Perhaps it’s best to find a way to make Nunavut emit the support code along with generated classes?

[scottdixon]

Hmm. Well, I suppose we could move this into Nunavut and add a concept of “supporting source” that isn’t generated. We’d also want to provide a packaging concept that would allow generation of python eggs or wheels, and c++ tar.bz or (perhaps) deb files. My biggest concern is how “thick” Nunavut will become because of this. It’s probably manageable given just Python, C, and C++ but if we start adding more languages the polyglot nature of this project may become unwieldy.

[pavel.kirienko]

I suppose we could move this into Nunavut and add a concept of “supporting source” that isn’t generated.

Makes sense (but see below). Surely we’re going to need something equivalent for C++ and friends as well.

We’d also want to provide a packaging concept that would allow generation of python eggs or wheels, and c++ tar.bz or (perhaps) deb files.

I don’t quite follow why though. Why would one need to package autogenerated code when it can be just re-generated on-demand instead? High-DAL software comes to mind, but it is unlikely to benefit from pre-packaged units either way.

if we start adding more languages the polyglot nature of this project may become unwieldy.

Yeah. Perhaps we could consider this alternative I mentioned earlier:

Library-independent code generation

So maybe instead of templates we could ship dedicated Python modules that can be also run as CLI tools, one per target language? nnvg-python , nnvg-cpp , etc.

[scottdixon]

but it is unlikely to benefit from pre-packaged units either way.

Yeah, once again, you’re right.

So maybe instead of templates we could ship dedicated Python modules that can be also run as CLI tools, one per target language? nnvg-python , nnvg-cpp , etc.

My monorepo dreams die a little more each day. Okay. I can see that helping. So we’d have pypi packages for python, c, c++ that depended on nunavut; correct?

[pavel.kirienko]

So we’d have pypi packages for python, c, c++ that depended on nunavut; correct?

That is what I was describing, yes, but I am still not sure which option is worse:

• Keeping every language inside the Nunavut core.
• Have many tiny separate repositories and PyPI packages depending on Nunavut.

By mentioning the alarming mortality rates among your monorepo dreams, I suppose you were implying that you prefer the latter approach. I dislike both equally so whatever.