docker compose -f docker-compose-image-tag.yml up fails with "uv: command not found"

[2af]

Bug description

I follow the quickstart guide and at the step of
docker compose -f docker-compose-image-tag.yml up
It downloaded all the images and after the DB and REDIS containers initialized all the other containers were constantly spamming the output with messages like:

superset_app          | Reinstalling the app in editable mode
superset_app          | /app/docker/docker-bootstrap.sh: line 24: uv: command not found
superset_worker_beat  | Reinstalling the app in editable mode
superset_worker_beat  | /app/docker/docker-bootstrap.sh: line 24: uv: command not found

I was able to start Superset with
docker compose -f docker-compose-non-dev.yml up

How can I troubleshoot what happened with the suggested
docker-compose-image-tag.yml
flow?

Screenshots/recordings

No response

Superset version

master / latest-dev

Python version

Not applicable

Node version

Not applicable

Browser

Not applicable

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

Hey @2af! I'm here to help you with any bugs, questions, or contributions. Let's tackle this together!

The error message you're encountering, /app/docker/docker-bootstrap.sh: line 24: uv: command not found, indicates that the uv command is missing in the Docker container environment. The uv command is expected to be available as it is used for creating a virtual environment and installing packages in the Superset Docker setup ^[1].

To troubleshoot this issue, you can try the following steps:

1. Check Dockerfile: Ensure that the Dockerfile used in the docker-compose-image-tag.yml setup includes the installation of uv. It should have a line similar to RUN pip install --no-cache-dir --upgrade uv.

2. Rebuild the Image: If the Dockerfile is correct, try rebuilding the Docker image to ensure that all dependencies, including uv, are properly installed. You can do this by running:

   docker compose -f docker-compose-image-tag.yml build --no-cache

3. Verify Installation: After rebuilding, verify that uv is installed by checking the logs during the build process for any errors related to the installation of uv.

4. Environment Variables: Ensure that the environment variables and paths are correctly set in the Dockerfile or Docker Compose configuration to include the directory where uv is installed.

If these steps do not resolve the issue, you might want to compare the configurations between docker-compose-image-tag.yml and docker-compose-non-dev.yml to identify any differences that could affect the installation or availability of uv.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[kidzen]

same here

[small-flowers]

I have also encountered the same problem. How can I solve it?

[maeddes]

I have the same issue on different platforms. It seems that the uv command got added in some files, e.g. docker/docker-boostrap.sh however it is not present in the underlying superset container image.

Temporary workaround is to go back to a version previous to the commits of December, e.g. https://github.com/apache/superset/releases/tag/4.1.1

git fetch --tags if you cloned with depth=1 and git checkout 4.1.1 made my docker compose work again with the docker-compose-image-tag.yml file.

I still think there will be a patched base image soon.

[javalram-ow]

same here

[Lucas-87an]

1. Lack of the package that provides the uv command:
   The uv command may be related to the uvicorn package, which is a popular ASGI server for Python applications such as Apache Superset.
   If uvicorn is not installed correctly in the environment, the system will not be able to find the uv command (which would normally be a shortcut to uvicorn itself).

in the docker-bootstrap.sh file it worked like this for me
set -eo pipefail

Ensure uvicorn is installed

pip install uvicorn

Make python interactive

if [ "$DEV_MODE" == "true" ]; then
echo "Reinstalling the app in editable mode"
pip install -e .
fi

REQUIREMENTS_LOCAL="/app/docker/requirements-local.txt"

If Cypress run – overwrite the password for admin and export env variables

if [ "$CYPRESS_CONFIG" == "true" ]; then
export SUPERSET_CONFIG=tests.integration_tests.superset_test_config
export SUPERSET_TESTENV=true
export SUPERSET__SQLALCHEMY_DATABASE_URI=postgresql+psycopg2://superset:superset@db:5432/superset
fi

if [[ "$DATABASE_DIALECT" == postgres* ]] ; then
echo "Installing postgres requirements"
pip install -e .[postgres]
fi

Make sure we have dev requirements installed

if [ -f "${REQUIREMENTS_LOCAL}" ]; then
echo "Installing local overrides at ${REQUIREMENTS_LOCAL}"
pip install --no-cache-dir -r "${REQUIREMENTS_LOCAL}"
else
echo "Skipping local overrides"
fi

case "${1}" in
worker)
echo "Starting Celery worker..."
# setting up only 2 workers by default to contain memory usage in dev environments
celery --app=superset.tasks.celery_app:app worker -O fair -l INFO --concurrency=${CELERYD_CONCURRENCY:-2}
;;
beat)
echo "Starting Celery beat..."
rm -f /tmp/celerybeat.pid
celery --app=superset.tasks.celery_app:app beat --pidfile /tmp/celerybeat.pid -l INFO -s "${SUPERSET_HOME}"/celerybeat-schedule
;;
app)
echo "Starting web app (using development server)..."
flask run -p 8088 --with-threads --reload --debugger --host=0.0.0.0
;;
app-gunicorn)
echo "Starting web app..."
/usr/bin/run-server.sh
;;
*)
echo "Unknown Operation!!!"
;;
esac

[krisbarker]

Yes, I've just had the same problem.

[mistercrunch]

Can you try compose -f docker-compose-image-tag.yml up --build ?

I modified the docs recently to instruct people to use --build. It's kind of the same as running docker compose build && docker compose up

[small-flowers]

I have the same issue on different platforms. It seems that the uv command got added in some files, e.g. docker/docker-boostrap.sh however it is not present in the underlying superset container image.

Temporary workaround is to go back to a version previous to the commits of December, e.g. https://github.com/apache/superset/releases/tag/4.1.1

git fetch --tags if you cloned with depth=1 and git checkout 4.1.1 made my docker compose work again with the docker-compose-image-tag.yml file.

I still think there will be a patched base image soon.

你能嘗試嗎compose -f docker-compose-image-tag.yml up --build？

我最近修改了文档，以指导人们使用--build。这有点类似于运行docker compose build && docker compose up

I used docker compose -f docker-compose-image-tag.yml up --build to execute, but the problem still persists. Please refer to the screenshot for the error message

Can you try compose -f docker-compose-image-tag.yml up --build ?

I modified the docs recently to instruct people to use --build. It's kind of the same as running docker compose build && docker compose up

[javalram-ow]

A quick workaround is to modify the scripts which use uv. Substituting uv pip by just pip removes the errors. I did these modification in docker/docker-bootstrap.sh and docker/pip-install.sh and worked. As mentioned in the previous comments, the apache/superset image must be updated to include uv so it does not throw up this error when building.

[sfirke]

Users are reporting this has broken the quickstart https://superset.apache.org/docs/quickstart/#2-start-the-latest-official-release-of-superset. Requiring users to build an image doesn't seem appropriate for a quickstart.

I think the ideal fix would be to modify the docker-associated files that reference uv to work with the latest release 4.1.1. That could be reverting or some kind of logic. It won't be necessary at the next major release but we shouldn't leave quickstart broken that long.

An immediate fix would be to add a note to the quickstart docs documenting this problem and pointing users to checkout the 4.1.1 tag and run from there as documented above by @maeddes #31510 (comment). I can submit a PR for this.

[mistercrunch]

Oh. Right. Didn't think this through. The bootstrap script uses uv and uv is not in older images. Also --build doesn't do anything to docker-compose-non-dev and the image-base one as we reuse old binaries there. Let me look into this and report back.

Ok the core issue is related to this line https://github.com/apache/superset/blob/master/docker-compose-image-tag.yml#L30 - docker-compose mounts the docker/ folder, meaning it's using whatever is in the branch you have checked out's docker entrypoints as opposed to the ones in the image itself. Removing that line may fix things, but the entrypoints are overriden, so we'll have to make sure that either: the entrypoints defined in the compose files do indeed exist on the old image.

[mistercrunch]

This should help -> #31588

[mistercrunch]

I added a documentation note in #31588 which recommends (at least for now) checking out release tag you're trying to release prior to executing docker-compose.

A bit of a retro on this is when I altered the docker-compose process, I didn't know or think about the fact that we mount docker/ on docker-compose-.*.yml, and use whatever is in the branch that's checked out against the image the user points to.