# Pyuavcan -\> Nunavut migration? **URL:** \ **Category:** Nunavut\ **Created:** [October 3, 2019, 6:25am UTC](https://forum.opencyphal.org/t/pyuavcan-nunavut-migration/636 "2019-10-03T06:25:40Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [October 3, 2019, 6:25am UTC](https://forum.opencyphal.org/t/pyuavcan-nunavut-migration/636/1 "2019-10-03T06:25:40Z")
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](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++. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [October 3, 2019, 8:15am UTC](https://forum.opencyphal.org/t/pyuavcan-nunavut-migration/636/2 "2019-10-03T08:15:07Z")
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? ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [October 3, 2019, 11:33pm UTC](https://forum.opencyphal.org/t/pyuavcan-nunavut-migration/636/3 "2019-10-03T23:33:37Z")
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. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [October 4, 2019, 12:11pm UTC](https://forum.opencyphal.org/t/pyuavcan-nunavut-migration/636/4 "2019-10-04T12:11:28Z")
> [@scottdixon](#): > > 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. > [@scottdixon](#): > > 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. > [@scottdixon](#): > > 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](https://forum.opencyphal.org/t/library-independent-code-generation/589/3): > [@Library-independent code generation](https://forum.opencyphal.org/t/library-independent-code-generation/589/3): > > 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. ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [October 4, 2019, 8:24pm UTC](https://forum.opencyphal.org/t/pyuavcan-nunavut-migration/636/5 "2019-10-04T20:24:32Z")
> [@pavel.kirienko](#): > > but it is unlikely to benefit from pre-packaged units either way. Yeah, once again, you’re right. > [@pavel.kirienko](#): > > 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? ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [October 4, 2019, 8:31pm UTC](https://forum.opencyphal.org/t/pyuavcan-nunavut-migration/636/6 "2019-10-04T20:31:32Z")
> [@scottdixon](#): > > 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.