Skip to content

Create a single docker image for python? #13686

Open

Description

@yeikel

Code improvement description

The docker and uv images are essentially the same, with only very minor differences:

https://github.com/dependabot/dependabot-core/blob/f746ee0f46732b48fd535088d6c81e7491888529/python/Dockerfile
https://github.com/dependabot/dependabot-core/blob/f746ee0f46732b48fd535088d6c81e7491888529/uv/Dockerfile

One difference in uv

# Install uv by copying from the official image
COPY --from=uv /uv /uvx /usr/local/bin/

I understand that this separation allows the ecosystem docker build to evolve independently, but in practice it often results in duplicated changes such as #13321 and missed bug fixes such as in #13630.

Would it make sense to consolidate these into a single build?

For example, the Python ecosystem image could be built first and then used as the base for the uv ecosystem

Activity

  1. yeikel commented on Dec 2, 2025

    @yeikel
    ContributorAuthor

    @jeffwidman From what I can tell, you are the main author of the python docker build. What do you think of this take?

  2. yeikel commented on Dec 2, 2025

    @yeikel
    ContributorAuthor

    For clarity, I am not expecting the team to tackle this right now given the known capacity challenges. I can give it a go provided we agree that it is a good idea.

  3. jeffwidman commented on Dec 2, 2025

    @jeffwidman
    Member

    LOL, I filed pretty much this exact ticket on our internal issue tracker yesterday morning. So I clearly think it's a good idea.

    We generally want to avoid tight coupling between ecosystems so I don't know if there should be a single parent docker image that both inherit from, or if uv should inherit from python... I don't know the solution, just that what we've got is a problem.

    Additionally, the fact that the rust dockerfile is pretty much copy/pasted into both python and uv results in a bit of a mess as well.

    As you alluded to, the business has me focused elsewhere lately, so I don't have the capacity to personally be too involved, but I'm sure the team focused on core would be happy to review if you want to give it a go. I do think it's a good idea. 👍

  4. markhallen commented on Dec 4, 2025

    @markhallen
    Contributor

    @yeikel this was on my radar. If you want to raise a PR I will review it. Thanks

  5. yeikel commented on Dec 7, 2025

    @yeikel
    ContributorAuthor

    Thanks @markhallen

    I took a closer look and I have a few notes/questions:

    1. It looks like the biggest challenge will be the native helpers. From what I can tell, we rebuild the helpers for each Python version, and the uv and python ecosystems use slightly different helper codebases. The differences are small, but they exist. This potentially means that unless we align these two, it won't be possible to avoid the two builds

    RUN bash /opt/python/helpers/build $PY_3_10

    1. I’m not fully familiar with how the split was done, but it appears there’s still some leftover code from the python ecosystem inside uv. For example, my understanding is that uv and poetry aren’t directly related, yet there’s poetry-related code as well as a dependency on it within the uv ecosystem. Is that intentional?

  6. yeikel commented on Dec 10, 2025

    @yeikel
    ContributorAuthor

    I'll go ahead and assume that poetry is not needed in the uv ecosystem as the documentation states clearly that poetry support is under the pip ecosystem

    @markhallen If you get a minute to confirm this, it'd help to accelerate any future review

  7. markhallen commented on Dec 11, 2025

    @markhallen
    Contributor

    I'll go ahead and assume that poetry is not needed in the uv ecosystem as the documentation states clearly that poetry support is under the pip ecosystem

    @markhallen If you get a minute to confirm this, it'd help to accelerate any future review

    Yes. This was not included intentionally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions