Granian + free-threaded python

[mvdbeek]

Support for PEP 703. Information on https://py-free-threading.github.io/

PYTHON_GIL=0 PYTHONPATH=lib \
GALAXY_CONFIG_FILE=config/galaxy.yml \
GALAXY_CONFIG_OVERRIDE_DATABASE_CONNECTION="postgresql+psycopg://localhost/galaxy" \
granian --interface asginl \
--host 127.0.0.1 --port 8090 \
--workers 6 \
--runtime-threads 2 \
--factory \
'galaxy.webapps.galaxy.fast_factory:factory'

works with a little bit of dependency tweaking:

• I stubbed out orjson, which will probably support free-threading for python 3.15
• switch to psycopg3 (a good thing to do anyway)
• and of course building everything that doesn't have free-threaded wheels

In theory this should allow for better CPU utilization, concurrency (to be benchmarked), without having to resort to gunicorn's --preload or over-allocating memory. I'm also interesting in seeing how well the backpressure controls work.

We should explore making (threaded) granian our (default) server for CI tests and add granian as an option to gravity.

Packages missing free-threaded builds:

• ct3
• google-crc32c Add Python 3.14 free-threading build support googleapis/google-cloud-python#15670
• grpcio Support no-GIL (free-threaded) Python grpc/grpc#38762
• mercurial 7.2 fails to build locally
• orjson 3.11.7 fails to build locally
• pycryptodome 3.23.0 Support Python 3.14(t) and build 3.14(t) wheels Legrandin/pycryptodome#891 , solved upstream in Legrandin/pycryptodome@58f0617 but needs a new release
• pysam 0.23.3: cp314t wheels built on wheelforge Build free-threaded cp314t pysam wheels wheelforge#65
• ruamel.yaml-clib 0.18.17: dependency removed in ruamel.yaml 0.19.1
• temporalio [Feature Request] Research and make SDK free-threading capable/compatible temporalio/sdk-python#928
• tokenizers Add cp314t tests, mark extension modules as compatible, and ship free-threaded wheels huggingface/tokenizers#1784
• tornado Support for free-threaded CPython tornadoweb/tornado#3501
• zstandard: free-threaded wheels are built and tested, but not uploaded to PyPI yet

Packages with problematic dependencies:

• cwl-upgrader 1.2.14: depends on ruamel.yaml < 0.19. Fixed in cwl-upgrader 1.2.15. Update ruamel-yaml requirement from <0.19,>=0.16.0 to >=0.16.0,<0.20 common-workflow-language/cwl-upgrader#203 (comment)
• cwl-utils 0.40: depends on ruamel.yaml < 0.19. Fixed in cwl-utils 0.41 Update ruamel-yaml requirement from <0.19,>=0.17.6 to >=0.17.6,<0.20 common-workflow-language/cwl-utils#399 (comment)
• h5grove: depends on orjson
• schema-salad 8.9.20251102115403: depends on ruamel.yaml < 0.19. Fixed in 8.9.20260327095315 build(deps): update ruamel-yaml requirement from <0.19,>=0.17.6 to >=0.17.6,<0.20 common-workflow-language/schema_salad#997 (comment)
• ruamel.yaml 0.18.17: depends on ruamel.yaml-clib. The dependency has been removed in 0.19.1

[nsoranzo]

Exciting! Do you already have a list of our dependency packages that don't currently have free-threaded wheels?
We could open/track upstream issues and build our own wheels on wheelforge in the mean time.

[mvdbeek]

Not yet, I suppose things might change until 3.15 gets released (or we decide to hack around h5grove, which brings in orjson). I'll make a list though.

[natefoo]

and of course building everything that doesn't have free-threaded wheels

I'm sure they're all free thread safe 😅

We could probably drop a huge amount of our dependency hell for the web application server itself by separating out datatype set_meta and other non-web functionality and continuing to run that on GIL python?

[mvdbeek]

Yes, that is another good goal, but that would also require untangling set_meta from things that the web app accesses. We should probably not be using pysam from a web thread for instance ... . Containerized set_meta would be another option / addition

[natefoo]

I'd very much like to move to containerized set_meta asap

[mvdbeek]

We'd need to think through how building, deployment and development are going to work there.

[mr-c]

@mvdbeek FYI https://pypi.org/project/schema-salad/8.9.20260327095315