CLI: Python version support?

26 views
Skip to first unread message

Mitch Keller

unread,
Jun 10, 2025, 10:27:44 AMJun 10
to 'Rob Beezer' via PreTeXt development
Something for CLI consideration that David A and I talked about in Greeley but I don’t think had a chance to bring up with Oscar: Can the Python version support for the CLI be updated? 3.8 was EOL in October 2024, and 3.9 will be EOL this October. Supporting those seems like a bad idea, honestly.

As more folks jump onto using PreFigure, catching up on version support may be helpful. Here’s a summary of what’s in the requirements.txt for prefig, where as you will see, almost all of the somewhat old versions being required is to maintain Python 3.8 support:

  • networkx: PreFigure requires networkx 3.1, which was released over two years ago. The current version of networkx is 3.5, which requires Python 3.11. (3.4.2 would work with Python 3.10.)
  • scipy: PreFigure requires scipy 1.10.1, which was released over two years ago. The current version of scipy is 1.15.3, which requires Python 3.10.
  • lxml: PreFigure requires 5.2.2, which it appears David could update as the CLI is calling for ^5.3, unless PreFigure is relying on something in lxml 5.2.2 that changed in a subsequent version.
  • numpy: PreFigure requires 1.24.4, which was released nearly two years ago. The current version of numpy is 2.3, which requires Python 3.11. (2.2.6 would work with Python 3.10.)
  • pycairo: PreFigure requires 1.26.0, which was released a year ago. The current version is 1.28.0, which requires Python 3.9.

There seems to be little downside to removing support for Python 3.8 and 3.9, and potentially some upside for PreFigure. I’m not sure if there would be any meaningful negative consequences to removing support for Python 3.10, but selfishly it would mean that networkx could get up to the current version while I’m needing to create a bunch of network diagrams in PreFigure :)

Steven Clontz

unread,
Jun 10, 2025, 10:43:46 AMJun 10
to PreTeXt development
I see no reason* to maintain 3.9 support, and second an upgrade to 3.10 as of the next minor release.

(*of course I don't, everyone should be using Codespace VMs where it's trivial to use the latest Python) 🙃

David Austin

unread,
Jun 10, 2025, 11:00:04 AMJun 10
to prete...@googlegroups.com
I very much support this request for all the reasons Mitch describes.  

David

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/cd90b36b-bb21-4125-80f8-7d336a658d62n%40googlegroups.com.

Mitch Keller

unread,
Jun 10, 2025, 11:08:58 AMJun 10
to prete...@googlegroups.com


On Jun 10, 2025, at 9:43 AM, Steven Clontz <steven...@gmail.com> wrote:

…everyone should be using Codespace VMs where it's trivial to use the latest Python) 🙃

First I’ll say my grumpy old man bit, but then I’ll pose a question about the devcontainer model more broadly, where I’m actually intrigued about potential :)

I personally find Codespaces obnoxious for routine use. I want my web browser to be a web browser. I want my email client to be an email client. I want my calendar to be a calendar. I want my IDE to be an IDE. Codespaces are handy for getting folks started and for doing a quick edit when you don’t have everything opened up (or are on a more limited device such as an iPad), but I just saw enough glitchy behavior during the Greeley workshop to make me firmly against routine usage.

(I’ll also throw in my extreme outlier reason in that we’re preferring GitLab over GitHub here at UW, and they don’t have Codespaces. I am going to get with our IT team about seeing if we can get the compute resources set up to have GitLab Workspaces enabled on our projects though for the startup and convenience reasons I mentioned earlier.)

OK, now to the devcontainer question where I see potential. VS Code has lately been asking me if I want to open projects in a container. I decided to give it a whirl. (I already had Docker installed on my Mac…I need to try with my other machine that doesn’t have Docker installed to see if it prompts me to install Docker or what happens.) Immediate fail because the images (either oscarlevin:pretext or the Microsoft one currently used by what the CLI creates) don’t support Apple Silicon. Installing Docker is a breeze (since you can get an app), so this seems like it could be a nice combination of Steven’s love of Codespaces and my preference for running standalone apps. (As it set itself up on my machine, it also saved the files locally so that I didn’t have to worry about what’s in the container/Codespace and what’s actually securely saved and not subject to garbage collection of one flavor or another.)

I forked Oscar’s pretext-docker repo at https://github.com/mitchkeller/pretext-docker and added multiplatform support in the docker-publish.yml file by adding `platforms: linux/amd64,linux/arm64` in the `with` section. Lite and small both built and deployed to DockerHub just fine. However, full ran into an issue. It appears that it ran out of space, and I don’t know enough about the workflow and Docker to debug that. However, when I stopped trying a multiplatform build of `full` so that I had a completed process, I was able to use the mitchkelleruw/pretext:small inside my devcontainer in VS Code quite elegantly. 

I tried looking at the Docker images Microsoft provides, and it looks like the ones that support arm64 don’t have all the bits PreTeXt will want installed by default. (For instance, using a Python-centric image meant I didn’t have Node and thus PreFigure didn’t work.) However, it’s probably possible to add some scripts that pull those things in, if using the MS images is preferable to using Oscar’s.

OK, that’s a long way of getting to the point of asking: Can someone who knows Docker better than me change how the default .devcontainer is set up so that it can be used in VS Code running locally (and Codespaces, of course) with Mac support?

-- 
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/cd90b36b-bb21-4125-80f8-7d336a658d62n%40googlegroups.com.

Oscar Levin

unread,
Jun 12, 2025, 10:42:00 AMJun 12
to PreTeXt development
My only hesitation with removing support for 3.8 is that pretext proper (and Rob) still wants to support 3.8, and I don't remember exactly why.  I don't think this should stop us, but it might make the documentation confusing?

As for the devcontainer and docker image... ugh!  This has so much promise and has taken so much of my time from other things.  Okay, done complaining now.  Mitch and David, if you are available and want to, there are drop-in hours today 10-12 MDT and we can chat.  I'm going to play around some more (I think I got passagemath working for sage support, which should make the images smaller).  

My main concern with promoting the local devcontainer setup is that for someone with LaTeX already installed, we are suggesting that they download a huge duplicate virtual machine to run pretext.  But maybe we can minimize the docker image so this is less of a con.

Sean Fitzpatrick

unread,
Jun 12, 2025, 10:52:55 AMJun 12
to prete...@googlegroups.com

I haven't used codespaces much for all the reasons Mitch mentioned, and I'll also add that sometimes I want to be able to work while I'm out somewhere, and I don't want to bother tethering my phone to get Internet access.

I haven't tried the docker containers because everything PreTeXt needs is installed on my computer anyway.
(Except for sage, but I don't use it in any projects.)


Rob Beezer

unread,
Jun 15, 2025, 3:11:01 PMJun 15
to prete...@googlegroups.com
On 6/12/25 07:42, Oscar Levin wrote:
> My only hesitation with removing support for 3.8 is that pretext proper (and
> Rob) still wants to support 3.8, and I don't remember exactly why.  I don't
> think this should stop us, but it might make the documentation confusing?

For the pretext/pretext.py module, and its simple interface at
pretext/pretext, I make a conscious effort to not use too many additional
modules and not to use "newer" features unless necessary. That way, folks with
older hardware, or long update cycles (Ubuntu LTS is supported for five years
and released every two years), or that build on this module, don't get caught out.

But I don't think that is relevant here. The CLI uses this module and it can
always use/require something newer.

FWIW, code comments/notes say 3.8 and beyond is supported, for both the
interface and the module. The vermin tool reports the same. Since 3.8 is EOL,
that can change whenever new code requires it.

Rob

Oscar Levin

unread,
Jun 16, 2025, 4:49:00 PMJun 16
to PreTeXt development
Okay, I'm on board with this.  Mitch, what version of python ships with MacOS?  I think anyone on Linux should be able to update their python one way or another.  And on Windows you need to download the latest anyway.

Mitch Keller

unread,
Jun 16, 2025, 4:56:43 PMJun 16
to prete...@googlegroups.com
Apple appears to no longer be shipping python with macOS. Homebrew’s python seems to be the most recommended. (I have 3.13 installed.) This is also generally easy to upgrade. Homebrew’s python now also shrieks at you if you try to pip install packages without using a virtual environment, which is good because it pip installs packages into directories based on the python version, so when you upgrade python, you need to reinstall your pip-installed packages.

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.

Sean Fitzpatrick

unread,
Jun 16, 2025, 6:26:51 PMJun 16
to prete...@googlegroups.com

Does Homebrew have something like pipx? A lot of Linux distros also don't allow pip install without a venv, and pipx is a pretty good workaround, even if its syntax doesn't align with pip.

It automatically creates and manages virtual environments. The main thing I like is that you don't have to remember to activate the environment...


Mitch Keller

unread,
Jun 16, 2025, 6:53:16 PMJun 16
to prete...@googlegroups.com
Yes, if I search for pipx as something I can install with Homebrew, it’s there.

Sean Fitzpatrick

unread,
Jun 16, 2025, 7:21:17 PMJun 16
to prete...@googlegroups.com

It won't serve every possible need, but I find it very convenient.

One catch: there's a difficulty with installing browsers for playwright.


Reply all
Reply to author
Forward
0 new messages