GNU bug report logs - #70265
Add docker cli Guix Home service and some docker authentication plugins

Previous Next

Full log

View this message in rfc822 format

From: paul <goodoldpaul <at> autistici.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 70265 <at> debbugs.gnu.org, Andrew Tropin <andrew <at> trop.in>, Tanguy Le Carrour <tanguy <at> bioneland.org>, paren <at> disroot.org
Subject: [bug#70265] Add docker cli Guix Home service and some docker authentication plugins
Date: Thu, 16 May 2024 00:49:37 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.