Re: Python Tooling

On Mon, 31 Aug 2026 at 23:06, Tristan Partin <tristan(at)partin(dot)io> wrote:

> On Mon Aug 31, 2026 at 8:38 PM UTC, Magnus Hagander wrote:
> > On Mon, 31 Aug 2026 at 22:32, Tristan Partin <tristan(at)partin(dot)io> wrote:
> >
> >> On Mon Aug 31, 2026 at 8:26 PM UTC, Jonathan S. Katz wrote:
> >> > On 8/31/26 4:23 PM, Tristan Partin wrote:
> >> >
> >> >>> The basic answer is, "use whatever is in debian" because that's what
> >> it's
> >> >>> deployed on, and at this point that's trixie.
> >> >>>
> >> >>> That also means we do *not* want to change the dependencies to
> anything
> >> >>> other than whatr's there.
> >> >>
> >> >> Does this mean that we rely on the versions of Python packages within
> >> >> Trixie and the requirements.txt is basically ignored?
> >> >
> >> > FWIW I will use requirements.txt in my local environment, but that
> only
> >> > happens when it gets nuked, so it's a once-every-few-years ordeal.
> >> >
> >> > (I could probably get the pgweb env to load from a container; perhaps
> >> > this is a suggestion towards a Dockerfile?)
> >>
> >> Are you referring to deploying as a container or a devcontainer? To
> >> expand on what I am thinking that we should use native Python tooling to
> >> manage dependencies. For instance, we would encode all our dependencies
> >> in the pyproject.toml, and then actually run the server with `uv run
> >> ...`.
> >>
> >> Python tooling moves so much faster than Debian that I don't think it
> >> makes sense to depend on Debian for anything other than the base OS and
> >> maybe the Python interpreter.
> >>
> >
> > I think you're going to have a very steep uphill battle to fight to get
> > that done. Mainly because the vast majority of dependencies we have lack
> > the basic idea of a stable release/branch, LTS or whatever you want to
> call
> > it. Django itself does, which makes it work. But we don't have the
> > resources to go around and manually figure out which changes are needed
> to
> > which of our many apps whenever we're forced to upgrade something because
> > of a security update. For very little actual gain, since just sticking to
> > the supported versions has served us very well for many years.
>
> I hear your concerns. Two thoughts:
>
> 1) The fact that Debian is an LTS distro does not necessarily mean that
> security updates will get backported. For instance, if software xyz has
> a vulnerability in version 1.X that isn't fixed until version 2.3, it is
> seriously unlikely that Debian has the resources to maintain a forked
> version of 1.X with the security fix. As you said, most software doesn't
> maintain an LTS branch. Debian tracks CVEs affecting its current package
> set[0]. I counted 48 CVEs affecting Python and other Python packages.

I decided to look at one of these for an example: CVE-2026-47180[1]. It
> affects the python3-zeroconf package[2]. Trixie has version 0.147.0
> packaged, which was released just about a year ago. GitHub reports[3]
> that the CVE was fixed in 0.149.5, and affected versions are everything
> less than that. This CVE was published on 2026-05-21, so Debian has been
> knowingly vulnerable for over 3 months. If we managed our own
> dependencies, we could have updated the day of the disclosure to 0.149.5
> which was released 4 days before the CVE was published. I understand
> being able to do this requires resources and time...
>

Oh absolutely, it's far from perfect. The most important thing remains, of
course, to minimize dependencies against packages that don't have a stable
branch handling as much as at all possible.

> 2. But I think that this problem can largely be automated away. On other
> software forges (GitHub, etc.), you can have automations for bumping
> dependencies upon new releases, and the forges can notify you of
> security vulnerabilities in your dependencies. If we didn't want to move
> Git hosting to other forges, we could also do our own automations using
> systemd timers that automagically sends patches to the list when a new
> release of one of our dependencies is published.
>

Bumping a dependency is not the hard part. The problem arises when the
update is not compatible with what you're using. Then you need to also
figure out exactly how and rewrite your code to work with the new version,
before you can update it.

Having complete testing coverage helps with that insofar that at least you
will *know* that things will break. You still have to fix them, but you
won't accidentally push an update to production. But without that, there's
a huge risk of just suddenly breaking things, and then you're stuck.

(And yes, we've seen that happen numerous times with some of our other apps
we host, and it's an absolute PITA).

Out of curiosity, how often is the Debian server restarted to pull in
> new updates?
>

Generally depending on need. We do check for updates every couple of hours
normally, sooner if it's one of those "omg the world is ending"-security
alerts that hits the press...

//Magnus