Box 8.0.0 #4028

Activity

1. ipspace

   added

   enhancementNew feature or requestNew feature or request

   on Nov 5, 2026
2. DanPartelly commented on Nov 5, 2026

   

   DanPartelly

   on Nov 5, 2026

   Collaborator

   More actions

   Im looking forward to this one. If it works, we should definitely switch, as some distros move very fast.
3. jbemmel commented on Nov 5, 2026

   

   jbemmel

   on Nov 5, 2026

   Collaborator

   More actions

   Let’s add Python 3.15 support and deprecate 3.10 in 26.11 (with a warning when someone runs Netlab with the eol version), then remove it in 26.12

   3.10 is already not being tested in ci/cd iirc, it would just be a bump in the minimum required version

   We could consider distributing Netlab as a prebuilt ghcr Docker image with 3.15, and perhaps even a “no ansible” preview candidate. Netlab could become available as a set of auto-completed shell commands that invoke the Docker image
4. ipspace commented on Nov 5, 2026

   

   ipspace

   on Nov 5, 2026

   OwnerAuthor

   More actions

   Let’s add Python 3.15 support and deprecate 3.10 in 26.11 (with a warning when someone runs Netlab with the eol version), then remove it in 26.12

   Perfect. Will do.

   3.10 is already not being tested in ci/cd iirc, it would just be a bump in the minimum required version

   It is. We test the minimum version (3.10) and the two latest ones (3.13 and 3.14)

   We could consider distributing Netlab as a prebuilt ghcr Docker image with 3.15, and perhaps even a “no ansible” preview candidate.

   The challenge is that we have to execute stuff (for example, containerlab or docker exec) on the host, not within the container. I guess we could try whether nsenter from a privileged container works reliably.
5. jbemmel commented on Nov 5, 2026

   

   jbemmel

   on Nov 5, 2026

   Last edited by jbemmel

   Collaborator

   More actions

   The challenge is that we have to execute stuff (for example, containerlab or docker exec) on the host, not within the container. I guess we could try whether nsenter from a privileged container works reliably.

   Or alternatively we could create a thin host side executable (Python - any version - or Go based for example) that launches a container with the Netlab "backend" logic to generate configs. The backend could return the list of host commands to execute, and the frontend would do that

   e.g. netlab up would launch a container with the local directory mounted, the backend would produce the config files and a up.sh script, and then the frontend would run that. Similarly, it would generate down.sh etc

   up.sh could be produced by a Jinja template much like ordinary config files - one template per netlab command, specifically generated for the given topology