# Pyuavcan -\> Nunavut migration?

**URL:** <https://forum.opencyphal.org/t/pyuavcan-nunavut-migration/636>\
**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:** 1\
**Showing post:** 4

<div class="post-metadata">

**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")

</div>

> [@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.

---

_[View the full topic](https://forum.opencyphal.org/t/pyuavcan-nunavut-migration/636)._