Homepage GitHub

Pyuavcan -> Nunavut migration?


(Scott Dixon) #1

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

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) #2

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?


(Scott Dixon) #3

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) #4

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

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.

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


(Scott Dixon) #5

Yeah, once again, you’re right.

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) #6

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.