we may want to support specific options somehow to be passed down to the daemon's client initialization here

@runcom Yeah, support options is better choice, when to support this?
Before it, I think configure docker daemon with environment variables is a choice.

Though, in abstract, I’m not thrilled about a library changing its behavior using environment variables about which the caller has no idea and which the caller cannot prevent.

(I do realize that there are various commonly expected behaviors where something like that is expected and needed, and atomic: does use various hidden environment variables like that; this again might be one of these cases. I do want to make sure that we are making a conscious decision.)

Could this be done by passing the needed information (and only the needed information—what is the use case?) through types.SystemContext (and perhaps by parsing environment variables in skopeo’s contextFromGlobalOptions instead?

@hustcat this is what I had in mind, starting with env variables isn't enough to me as a start.

At the very least, the ImageSource implementation needs an equivalent change.

+1

For what it's worth, this pull request together with a change to daemon_src.go is what I needed tp connect to a remote Docker daemon. Environment variables works for me, since I use containers/image as a library and can set the env settings in the calling code. However, I agree that is is not really explicit.

Hi I created pull request #328 to supersede this pull request. The only difference is that it creates the Docker client from env variables for source and destination.

Maybe this is not the ultimate solution, but imo it would at least move things forward.

@mtrmac Please Close since other PR got merged.

Yeah, #328 should allow making the same choices as this PR.