Dragging a Snap Forward

A fun little project nebula-lighthouse-service that I host an instance of got a mention on Jupiter Broadcasting’s Linux Unplugged, which gave me a big reminder that it was overdue some maintenance, so lets step through what is needed and what was changed since v1.8.2.

The project is functionally tied to being a snap at the moment so there was three things that needed to be checked and addressed:

1. nebula

Updating nebula version was pretty straight forward there was only one depreciation in v1.9.0 affecting default_Local_cidr_any and local_cidr which are not used by the lighthouse, building nebula is also very straight forward so just a simple version bump here to v1.9.6.

2. snap core

Snaps are made by building on top of the base snap’s which are essentially cut down Ubuntu LTS environments, the snap was using core20 which is based on Ubuntu 20.04 LTS and this is actually already out of support. This could be bumped to core22 or core24, I figured core24 meant longer support and maybe pick up a couple of the performance improvement that come with the newer software versions. The changes of core20->24 that I can see is python 3.8->3.12, go-lang 2.1.13->2.1.22 and gcc 1.185->1.214. go-lang is also not included in the base core24 snap so that needed to be added in as a build package in the nebula part. There was also a hook that needed to be updated to point at the python 3.12 library instead of 3.8 .

3. python dependencies

With the python upgrade pretty much all the dependencies need to be upgraded to a version that supports 3.12. The dependencies were:

• fastapi 0.75.1
• PyYAML 6.0
• uvicorn 0.17.6
• pydantic 1.9.0
• python-multipart 0.0.5

Looking through the release notes most of them did not have any depreciation notices. pydantic has a v2 release but v1 is still supported so that can be something that is bumped to another day. fastapi had a change in it’s packaging from 0.112.0 (because of course it’s turtles all the way down) where the default fastapi dropped a few packaged dependencies and fastapi[standard] kept the same ones. I decided the first sane step was to get some functionality on python 3.12 and then look at how far I could go after that.

• PyYAML had a minor bump so straight to 6.0.2
• uvicorn only needed to go to 0.24.0 but no features that I could see used had a depreciation notice so I bumped it straight to 0.35.0
• python-multipart this is actually included in fastapi so initially I removed it (no reason to not push it to the latest 0.20.0 though)
• pydantic had a number breaking of changes in 1.10.0 but none that seemed to affect the usage here, I have not brought myself to look at the migration guide to v2 yet.
• fastapi changed what dependencies it pulled in from 0.112.0 and at least 0.109.0 was needed for python 3.12 support so I changed the release to 0.111.1, rebuilt and gave the snap a quick test of the basic functions. functionality seemed fine so I bumped to it to 0.112.0 which is broken into fastapi and fastapi[standard] looking at the difference it seemed only python-multipart was missing from fastapi so bumping to 0.112.0 and a quick test was easy and then I pushed it all the way to the latest 0.116.1, all the breaking changes did not effect any of that calls were used in the snap.
• python-multipart has no breaking changes so it should be a straight forward, initially I dropped it as it was included in fastapi 0.111.1 (only at 0.0.7) but it was dropped from fastapi in the 0.112.0 change so I ended up adding it back in at 0.0.20
• pkg_resources > importlib.resources was an unexpected one, after pushing fastapi to 0.111.1 and doing some basic testing I saw a depreciation warning for pkg_resources. looking at the usage resource_string is used to serve the main HTML page, I have not done much python coding so it took a bit of reading and experimenting but importlib.resources.files().joinpath().read_bytes() returned the file contents in the same byte format so that all the HTML encoding was not altered.

After that I manually ran though testing all the functions if the snap and submitted two pull request 1 2.

What I learned

Along the way I learned that updating dependencies without having a simple command to test it can feel like stumbling around blind, and this snap is pretty small but still has a bit of setup thinking and going through the scenarios (I am playing around with using some NixOS stuff to test).