Facilitate usage of nerdctl as a library to build other clients

[apostasie]

What is the problem you're trying to solve

I do maintain a fork for my own use, that contains radical changes that do not fit here.

As such, I want "my" nerdctl binary to be named differently, and also use different config, storage locations and labels names to avoid conflicts.

Generally, people looking at building their own x-ctl should be able to leverage nerdctl codebase to do that.

The problem right now is that "nerdctl" is hardcoded in a bunch of places, making that task rather pedestrian and error prone.

Describe the solution you'd like

Suggesting that "nerdctl" strings across the codebase are reviewed and at least turned into constants that would be easy to change - or better, maybe we overload global config with a "Name" property that would default to "nerdctl" of course.

Let me know what the team here thinks about this use-case, and possible solutions.

Additional context

No response

[AkihiroSuda]

Suggesting that "nerdctl" strings across the codebase are reviewed and at least turned into constants that would be easy to change - or better, maybe we overload global config with a "Name" property that would default to "nerdctl" of course.

Probably this should be defined as a variable that can be overridden with go build -X ?

[apostasie]

Suggesting that "nerdctl" strings across the codebase are reviewed and at least turned into constants that would be easy to change - or better, maybe we overload global config with a "Name" property that would default to "nerdctl" of course.

Probably this should be defined as a variable that can be overridden with go build -X ?

Yeah, I like that ^.
Will send a PR.