How can I have the git package installed in the python SDK base image?

[brittle saddle]

Context:
I'm developing a python module that needs to know his own version. I'm using versioningit in my build-system pyproject.toml configuration for setting the module version at install/build time from the project git information:

...
[build-system]
requires = ["hatchling==1.27.0", "versioningit==3.1.2"]
build-backend = "hatchling.build"

[tool.hatch.version]
source = "versioningit"
default-version = "0.0.0+unknown"
...

I checked that the base image used does not contain git so my package is installed in this line https://github.com/dagger/dagger/blob/main/sdk/python/runtime/main.go#L416 with a default version.
I tried to use my own local image with git by configuring this in the pyproject.toml, but I suspect that the container of the dagger engine doesn't have access to my local images:

...
[tool.dagger]
base-image = "dummy/python:3.12-slim-git"
...

It is trying to search it in: docker.io/dummy/python:3.12-slim-git

I also tried using a local container registry this way:

...
[tool.dagger]
base-image = "localhost:5000/dummy/python:3.12-slim-git"
...

But it returns connection refused.

I need to be able to have git installed only for the developing environment.

Questions:
What do you think is the best approach in this case?
How can I provide a local image as the base image for the python dagger SDK module?

[pine quarry]

Yeah, the base_image setting needs access to a registry in order to pull the image. The local container registry should work though. Have you tried using that directly? Like:

dagger -M -c 'container | from localhost:5000/dummy/python:3.12-slim-git | terminal'

There's another way that doesn't require you to pre-build and publish an image which is to extend the SDK, but the downside is it has higher chance of breaking on Dagger upgrades. It's only meant to unblock some advanced use cases for power users.

[old otter]

localhost out of the box won't work in this context since the pull happens in the engine container. If you have the registry running in your local machine, it won't be able to connect to it.

@brittle saddle in order for the engine to be able to pull from a local registry, you need to start your registry container with --net container:$engine_container so the engine can actually reach to it via localhost 🙏

[brittle saddle]

Hi @pine quarry and @old otter !
With your explanations I managed to use the base-image solution by connecting the docker registry to the dagger engine through the --net argument and it is what I need for a development environment.
@pine quarry I don't follow how I can extend the python SDK locally for development.

[old otter]

@brittle saddle extending the SDK means creating a dagger module similar to the one that helder pointed to which has the python runtime as a dependency (https://github.com/dagger/dagger/tree/main/sdk/python/runtime) and you can override some functions like the codegen and module_runtime which will allow you to install any packages you need into the runtime image. Having said that, if you can proceed with the custom image approach, I'd recommend that

[pine quarry]

Yeah, extending the SDK is last resort, glad you could make the custom image work. We may support having a list in dagger.json with the OS packages to install when we have custom SDK specific configs in there. Git wasn't added by default because most don't need it and it adds to the module's load time.

[brittle saddle]

Oh, understood! I prefer the registry solution. Thank you for the support it's amazing.
Yeah, I supposed that was the reason not to include git.

For others that might want to use a docker registry I leave here the solution I implemented.