[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#70265] Add docker cli Guix Home service and some docker authenticat
From: |
paul |
Subject: |
[bug#70265] Add docker cli Guix Home service and some docker authentication plugins |
Date: |
Thu, 16 May 2024 00:49:37 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 |
Hello Ludo’ ,
I think you are raising a fair point. I was also not sure about whether
to upstream this service, even if I have been using it for some months.
On 5/4/24 18:36, Ludovic Courtès wrote:
A more general question: do you think this particular example (libsecret
plugin) could be solved in another way without involving Home? (For
example by having a plugin search path in the package.)
Do you have other use cases in mind?
My main use case for this is currently is docker compose v2. I packaged
the binary from github in my personal channel [0] and with this service
[1]in my home-environment I'm able to use docker compose (without dash)
commands.
The reason I’m asking is that it feels heavyweight for what looks like
“basic” Docker configuration.
It definitely is and whether to accept this patch imho depends on the
ETA for the optimal solution. Assuming someone packages docker compose
v2 and its dependencies, then as far as I'm aware there are are 3 ways
to make docker-cli aware of plugins on Guix:
1. this service, i.e. listing plugins in docker's configuration file.
the advantage of this solution is that it doesn't require changing the
docker-cli package. the disadvantage is that docker for some reason
always tries to write the following to the config file, even if it is
not needed :
"auths": { "https://index.docker.io/v1/": {} }
this is why i added it in the documentation, but as you pointed out it
is useless.
2. We make a docker-cli-with-bundled-plugins function or similar that
takes a list of plugin packages and hardcodes their paths into docker's
source code before compilation. This is the approach I took here [2].
This currently requires recompilation every time since docker compose v2
is not in guix.
3. We patch docker [3] to make it aware of plugins with a search path
like DOCKER_CLI_PLUGINS . But I don't think this patch should live in
Guix. It should go into docker mainline to make sure that it is
supported also in future releases. I never tried contributing to docker,
this does not seem a complex change but I wonder why it was never done
until now.
Given all of the above the shortest way to achieve my goal of using
docker compose v2 seemed #1 but I can see how for the Guix project the
best would be #3. What do you think (and everyone CCed as well)? Could
this service be a temporary workaround (after addressing your comments),
while I try to see whether docker mainline could be interested in a patch?
I will address your comments after we reach consensus on how to proceed,
so that I don't make everyone lose more time than I already have. Thank
you all for your work,
giacomo
[0]:
https://gitlab.com/orang3/small-guix/-/blob/master/small-guix/packages/compose.scm
[1]:
https://gitlab.com/orang3/guix-deployments/-/blob/main/modules/common/home/fishinthecalculator/home-configuration.scm?ref_type=heads#L71
[2]:
https://github.com/bonfire-networks/bonfire-app/blob/main/manifest.scm#L57
[3]:
https://github.com/docker/cli/blob/master/cli-plugins/manager/manager_unix.go