My company creates and distributes snaps in an IoT setting. Suddenly, the snaps had a 10% increase in size!! (edit: some were almost double their previous size)
It turned out this was because you turned on generation of .pyc files in the uv plugin:
I understand that it makes python initial startup time somewhat faster. But our use case is IoT and for us smaller downloads is more important… it was nicely documented, and easy enough to turn off again, but it caused us a small surprise and churn!
If I read the commit message correctly, this was done to make the uv plugin more ‘the same’ for people migrating from poetry or regular python to the uv plugin. But we WERE already on uv and for us this was not a great find!
Hi @mwb. I’ll rip off the band-aid and just say, I don’t think this change is likely to be reverted. The craft tools tend towards the default that makes the most sense for the broadest set of people, and I believe a lot of people will enjoy this free performance boost. The build still completes - we don’t take hardware limitations into account (other than architectures) when deciding if something should be considered a breaking change.
That all said, this is an easy behavior to disable. Just set UV_COMPILE_BYTECODE=0 on the respective part’s build-environment key. I’ll add a blurb to the plugin docs to clarify this as well.
I understand it is hard for snap to be all things for all people. But we use snapcraft for IoT on Ubuntu Core and I feel this and the added ‘linter’ for snapcraft.yml metadata that complains if there is no ‘donation’ link in your package are working against users like us. Sure we can turn this off again, and we did, just like we did with the linter warnings, but it’s annoying to say the least.
And of course I understand that snap has to battle against the perception of being ‘slow’ so you might want to ship with pyc files, but for instance .deb files definitely do not do that it seems bad practice to do so. If you feel you definitely need the added ‘performance boost’ (did you measure it?) as a trade-off against the snap package size – and remember, bigger snap size also means longer download – why don’t you compile the pyc on the client in a hook after installation of the snap?
it seems bad practice to do so. If you feel you definitely need the added ‘performance boost’ (did you measure it?) as a trade-off against the snap package size – and remember, bigger snap size also means longer download – why don’t you compile the pyc on the client in a hook after installation of the snap?