dockerconfig

[Casper Thomsen]

Hi,

Just like http://git-scm.com/docs/git-config#FILES it would be nice to
e.g. configure docker aliases that are scoped under the docker
command.

I guess there are other configurations that would make sense to have
in a ~/.dockerconfig? Should it be named like that? Does it already
exist?


Kindly,
--
Casper Thomsen

[James Mills]

What kind of configuration options are you referring to

that can't be easily solved by shell scripting

or shell aliases or an abstract tool on top of the Docker API?

cheers

James

James Mills / prologic

E: prol...@shortcircuit.net.au

W: prologic.shortcircuit.net.au

--
Casper Thomsen

--
You received this message because you are subscribed to the Google Groups "docker-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to docker-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Casper Thomsen]

On Thu, Mar 27, 2014 at 12:45 PM, James Mills
<prol...@shortcircuit.net.au> wrote:
> What kind of configuration options are you referring to
> that can't be easily solved by shell scripting
> or shell aliases or an abstract tool on top of the Docker API?

None. I refer to why git-config exists.

Rather than we all write our own `dockr` function that takes arguments and
constructs `docker` commands (e.g. `dockr ri $1` expands to `docker run -i -t
$1` etc.) it would be convenient to have e.g.

$ cat ~/.dockerconfig # Heavily ~/.gitconfig inspired.
[alias]
ri = run -i -t
rri = run -rm -i -t
rd = run -d
ip = inspect -format '{{ .NetworkSettings.IPAddress }}'
[color]
ui = true
[index.docker.io]
user = cathper

This is just a convenient way of configuring the docker client. Auto-completing
is possible by just looking at the aliases. When you create an alias, you won't
get functional auto-completion for container ids for instance.


Kindly,
--
Casper Thomsen

[James Mills]

I'm going to retort this a little bit...

Being a heavy Mercurial user (and I use Mercurial's hggit bridge to use Git repos too!)

I wouldn't use this approach personally myself at all.

Rather I would (and do) this:

$ cat .hgrc

[ui]

username = James Mills <j.m...@griffith.edu.au>

ignore = ~/.hgignore

[defaults]

revert = --no-backup

diff = -g

export = -g -o %%b-%%R:%%h.patch

email = -g

... For example ...

I would not be interested in aliasing "docker" commands

because it increases mental effort. I'd rather just have a

simple straight forward way of setting default options for

various commands -- Assuming such a ~/.dockerrc cottoned on at all.

(I would prefer .dockerrc over .dockercconfig)

cheers

James

James Mills / prologic

E: prol...@shortcircuit.net.au

W: prologic.shortcircuit.net.au

[Casper Thomsen]

On Fri, Mar 28, 2014 at 1:19 AM, James Mills
<prol...@shortcircuit.net.au> wrote:
> Rather I would (and do) this:
>
> $ cat .hgrc

(...)

> [defaults]
> revert = --no-backup
> diff = -g
> export = -g -o %%b-%%R:%%h.patch
> email = -g

Nothing prevents you from implementing the configuration to understand

[alias]
rev = revert
revert = revert --no-backup
diff = diff -g
etc.

with some given semantics. (I guess we would need "inverses" to options
if the Mercurial strategy is followed; so if "defaults.run = -rm" and
you do not want to "-rm", you should be able to do "docker run -no-rm"
or similarly. Or, how does Mercurial solve this?)

> I would not be interested in aliasing "docker" commands
> because it increases mental effort.

Noone forces you to create aliases, neither "scoped" nor shell aliases,
but I see people actually do both.

> I'd rather just have a simple straight forward way of setting default
> options for various commands -- Assuming such a ~/.dockerrc cottoned
> on at all. (I would prefer .dockerrc over .dockercconfig)

You're right, ~/.dockerrc is more aligned with everything else (but
git which is probably strange in this regard).


Kindly,
--
Casper Thomsen

[Michael Neale]

I was thinking the same thing - although I was thinking more how to specify to the docker command where the config file is - not so much implicit scope of config). 

My case: one docker command (and same user on the host) - with different registry configurations - currently it looks in $HOME/.dockercfg but being able to override may be useful (notwithstanding a context aware git-config like feature).