Building Trame app with Docker is impossible since Friday afternoon

[nathanWhitacre]

Ever since this past Friday afternoon (November 7), I've been unable to build my Trame application in Docker. I've verified through version control that this issue is independent of any changes I have made, and I can't find any info that the process needed to build through Docker has changed. I suspect this might be an issue with wheels.vtk.org. Has anyone else run into this issue and if so, have you found a solution?

Below is the text output for the Docker build step. It mentions that the requirement for aiohappyeyeballs is unsatisfiable, but this is just because it is the first line of my requirements.txt file (see further down). If I comment this requirement out or remove the version number specification it just throws the same error for the next one. I cannot afford to remove the version specifications from all of my requirements as some features of my app are dependent on them.

#9 [4/4] RUN /opt/trame/entrypoint.sh build
#9 0.303  * Restarting Apache httpd web server apache2
#9 0.345 AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
#9 1.354    ...done.
#9 1.354 Running build...
#9 1.765 Downloading cpython-3.13.5-linux-x86_64-gnu (download) (33.8MiB)
#9 3.515  Downloading cpython-3.13.5-linux-x86_64-gnu (download)
#9 3.680 Using CPython 3.13.5
#9 3.680 Creating virtual environment at: /deploy/server/venv
#9 3.681 Activate with: source deploy/server/venv/bin/activate
#9 3.843 Using Python 3.13.5 environment at: /deploy/server/venv
#9 4.175   × No solution found when resolving dependencies:
#9 4.175   ╰─▶ Because there is no version of aiohappyeyeballs==2.6.1 and you require
#9 4.175       aiohappyeyeballs==2.6.1, we can conclude that your requirements are
#9 4.175       unsatisfiable.
#9 4.175
#9 4.175       hint: `aiohappyeyeballs` was found on https://wheels.vtk.org/, but not
#9 4.175       at the requested version (aiohappyeyeballs==2.6.1). A compatible version
#9 4.175       may be available on a subsequent index (e.g., https://pypi.org/simple).
#9 4.175       By default, uv will only consider versions that are published on the
#9 4.175       first index that contains a given package, to avoid dependency confusion
#9 4.175       attacks. If all indexes are equally trusted, use `--index-strategy
#9 4.175       unsafe-best-match` to consider all versions from all indexes, regardless
#9 4.175       of the order in which they were defined.
#9 4.321 /deploy/server/venv/bin/python: Error while finding module specification for 'trame.tools.www' (ModuleNotFoundError: No module named 'trame')
#9 4.335 /deploy/server/venv/bin/python: Error while finding module specification for 'trame.tools.app' (ModuleNotFoundError: No module named 'trame')
#9 4.344 Build complete
#9 DONE 4.4s

Below is my requirements.txt file:

aiohappyeyeballs==2.6.1
aiohttp==3.12.13
aiosignal==1.3.2
attrs==25.3.0
certifi==2025.7.14
contourpy==1.3.2
cycler==0.12.1
fonttools==4.58.4
frozenlist==1.7.0
h5py==3.14.0
idna==3.10
kiwisolver==1.4.8
matplotlib==3.10.3
more-itertools==10.7.0
msgpack==1.1.1
multidict==6.5.0
numpy==2.3.0
packaging==25.0
pandas==2.3.0
parsli==1.2.5
pillow==11.2.1
propcache==0.3.2
pyparsing==3.2.3
pyproj==3.7.1
python-dateutil==2.9.0.post0
pytz==2025.2
PyYAML==6.0.2
scipy==1.16.1
six==1.17.0
trame==3.10.2
trame-client==3.9.1
trame-common==1.0.0
trame-components==2.5.0
trame-server==3.4.2
trame-vtk==2.8.17
trame-vtklocal==0.13.1
trame-vuetify==3.0.3
tzdata==2025.2
--extra-index-url https://wheels.vtk.org/
vtk==9.5.20250531.dev0
wslink==2.3.4
yarl==1.20.1
boto3

Here is my Dockerfile:

FROM kitware/trame:uv-glvnd

ENV TRAME_PYTHON=3.13.5

RUN apt-get update \
    && apt-get install -y \
    libxrender1 \
    && rm -rf /var/lib/apt/lists/*

COPY --chown=trame-user:trame-user . /deploy

ENV TRAME_CLIENT_TYPE=vue3

RUN /opt/trame/entrypoint.sh build

Any help is greatly appreciated as this is a significant blocker for development! Thank you!

[nathanWhitacre]

Updating this post to share that as of this morning (Friday, November 14), this issue appears to have been resolved.

If anyone experienced this issue or has any info about what caused it, please do share! Thank you!
If this was in fact an issue on Kitware's end, thank you to the devs for fixing it!

[jourdain]

Sorry I missed that message...

Yes Kitware had to setup some stronger rules on our firewall due to some dos or external robot load. In that process that removed access to our pypi index. We managed to find better rules yesterday which is solving this issue.

[nathanWhitacre]

Ah I see. Thank you for the info!