Have #insert_local allow for multiple files? about docker-api HOT 8 CLOSED

I like the idea of taking multiple files for Docker::Image#insert_local, you can expect that in the next version release. As for the String vs Symbol keys, I wanted to stay consistent with the way arguments are passed to the other methods. I know I could remedy this by including activesupport, but I'm weary of that because it adds a large dependency on a gem which is intended to be lightweight. If you've got any other ideas, I'd be happy to hear them.

from docker-api.

Regarding using symbols, couldn't you use to_s to convert arguments into the expected string arguments before using them? I don't think that would break backward compatibility.

from docker-api.

Fair point, as long as nobody gets sick passing camelCased symbols :)

from docker-api.

-1 on camel symbols: that would be surprising and could complicate eventual support for snake-case symbols.

from docker-api.

@bfulton Good point. Then why not something like,

local_path = opts.delete('localPath') || opts.delete(:local_path)

(This would replace https://github.com/swipely/docker-api/blob/master/lib/docker/image.rb#L49)

from docker-api.

@ulyssecarion reasonable approach there but could get messy if applied everywhere. @nahiluhmot is there an issue that tracks just the symbol key access? Might be helpful to refer to since it seems to come up along with other suggestions. Also, would it make sense to conditionally support symbol access if the activesupport class is defined?

from docker-api.

@bfulton I've looked into it a little, but the Remote API is a bit inconsistent regarding which type of camel case they use (i.e. camelCase vs CamelCase). This makes it difficult to make a general solution for the snake case symbolic key issue.

from docker-api.

Closing this because #37 was merged. Regarding the symbol to string conversion, I think we should open an issue, but given the lack of standard in the remote API this would probably end up looking hacky.

from docker-api.