From 0b266539ac091d82c94abc1eb64ccdb2c766e092 Mon Sep 17 00:00:00 2001 From: Philip Sargent Date: Thu, 17 Jul 2025 09:13:43 +0100 Subject: [PATCH] podman containerfile documn - online edit of handbook/troggle/troglaptop.html --- handbook/troggle/troglaptop.html | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/handbook/troggle/troglaptop.html b/handbook/troggle/troglaptop.html index 0c089333f..9c8b84523 100644 --- a/handbook/troggle/troglaptop.html +++ b/handbook/troggle/troglaptop.html @@ -108,15 +108,17 @@ which you can read without installing by looking in:

We have two configurations for the virtual environment: 'dev' which uses the latest python and Django for speed, and 'server' which mimics the versions currently running on the server. [In December 2024 Django is 5 releases ahead of the version on the server (5.1 versus 3.2). Each has a list of ancilliary packages with the appropriate versions in dev.toml and server.toml.] venv-trog.sh deals with all this python-specific stuff, libraries and Django plug-ins.

os-trog.sh takes a few minutes: it installs the subset of /expofiles/ you need to work with troggle. If you now want to install survex, therion etc. then run os-survey.sh, and go away for an hour, as these drag in a huge number of dependencies and installs all of /expofiles/ except the photos and Martin's mapapp. +

(Note that uv now makes everything much simpler than when were were using pip).

Why no Docker container?

-

Yes, it is true that this would greatly speed up on-boarding new programmers. Or podman. +

Yes, it is true that this would greatly speed up on-boarding new programmers. We have a Docker-compatible podman container in development (see Container build file) but this needs further work to remove live passwords from the built Container. This will currently build a Container (~6Gb) from a pre-existing fully-installed Troggle machine.

But there is the significant danger that containers would get copied around and deployed without being properly cleaned up: resulting in configuration drift and a snowflake server situation. File permissions are a big issue. -

We should do both: create a Docker or Podman system for getting started, then transition programmers to script-based or recipe-based -provisioning so that systems are rebuilt cleanly. CUYC (who also use Django) have a bash script which sets up a new django - development system. We should copy that in the first instance. Alas, we haven't got around to doing any of this yet. However uv now makes everything much, much simpler than when were were using pip. +

We should eventually have both a Container, for getting started quickly, and a separate recipe-based +build system so that systems are rebuilt cleanly from the basics, to avoid the snowflake issue. CUYC (who also use Django) have a bash script which sets up a new django + development system and we have something similar, but it is fragile. A recipe-based build system instead of a string of commands would be better, e.g. Qbs. +

Configuring ubuntu

Set up the key-exchange first. You need to be able to ssh into the server to run this next bit.